Skip to main content

Full text of "An introduction to local area networks"

See other formats


1508 
of a message. In a contention bus or contention ring network, 
the output machine may transmit only when the network 
is quiet. The "token present" signal is replaced by a "network 
quiet" signal. In the ring network, the reception control 
section signals the transmission control section if it detects 
another token in the midst of its receipt of the message the 
transmission control section sent; this has its analague in the 
collision detection capability of the contention network. In 
both cases, the LNI must abort transmission of its message 
and take corrective action. In the ring network this is an 
error condition, an exception; more than one control token 
is present in the ring. In the contention network, a collision 
is an expected event. Both situations can be handled by the 
LNI reporting the event to host software, which can attempt 
.to restart a token on the ring, in the ring network case, or 
a. pply a retransmission backoff algorithm in the contentiqn 
network case. 
A better solution for the contention network is to modify 
the transmission control section to execute a simple retrans- 
mission backoff algor/thm in hardware. This requires that 
the entire message remain accessible to the transmission con- 
trol section without host intervention. The FIFO buffer 
cannot be used in this situation; a complete packet buffer 
which is not erased until the message has been successfully 
transmitted is an appropriate alternative. 
Two features of the ring network LNI's transmission con- 
trol section are not needed in the contention bus network 
version: the data repeater which passes bits from the receive 
side of the LNI to its transmit side when the LNI is not 
transmitting a message, and the token generator which 
places a new token or connector onto a quiescent ring. Of 
course, the connector is'a brief sequence of bits, and there 
is no good motivation to delete it from the beginning of 
messages transmitted by the contention bus version of the 
LNI. In fact, retention of the connector at the head of a 
message results in fewer changes to the input machine of 
the LNI. It can use its token/connector detector to signal 
the beginning of an incoming message. Its function remains 
the same, for the most part; extra connectors detected in 
the middle of a message indicate a collision, just as they do 
for the r/ns network version. However, in the contention 
bus network, because bits are not repeated from one LNI 
to another, there is no way to set the match/accept bits for 
the benefit of the transmitting LNI, and the match/accept 
field of the message cannot be used. 
The signal conditioning section of the LNI undergoes an 
interesting transformation. For a contention ring network, 
of course, the signal conditioning section remains the same. 
However, 'for a contention bus network, the logic levels of 
the LNI must be converted to appropriate signal levels and 
waveforms for the coaxial cable of the bus. This is done in 
a two-step process. First, a cable transceiver is added to the 
configuration. To minimize impedence misma[ches, reflec- 
tions, etc., the transceiver is located immediately adjacent 
to the network cable, and is often packaged separately from 
the LNI. 4 It is connected to the cable either directly, or via 
4This has become common practice in local area networking; the 
networking transmission medium is generaIly not brought into the 
racks, equipment bays, etc., of a host computer where it wouId be 
subject to accidental disconnection and other physical abuse that 
could disrupt the entire network. Instead, the connection point for 
a host is designed to be physically stabIe: a box on the wall, above 
a false ceiling, etc. 
PP. OCEEDINGS OF THE IEEE, VOL. 66, NO. II, NOVEMBER 
coaxial Cable 
/ (e g., LNI ) 
host 
ground 
oplo- bus 
solator receiver 
opto* 
I isolated power supply 
cable ground reference - 
i 
single ground 
point for enlir.... 
cable 
//// 
Fig. 8. A typical bus transceiver. The opto-isolators and isolated 
supply permit the drivers and receivers to be referenced - 
ground; the cable, in turn, is grounded at only one poim ahmt 
length, eliminating problems that would result if each era,steiner 
the cable to local host ground. 
K et al.: 
basic 
a hig 
and 
tion of 
on 
way 
receive 
from 
be ab 
is 
o 
us. An 
req 
and 
Howeve 
netwo 
will 
Tkis 
jdn'vers. 
 more d 
i'.tli0 transce 
.signaling 
.ot drivir 
Itliminat ed. 
,b. lifted' 
us duhr 
nt duhn; 
constRue 
)out 1 kn 
a short stub cable attached to the main cable via a tap. x,-,transce 
and, since the transceiver is located adjacent to the nct ' ences at 
bus cable, and the LNI is located next to its host, an 
priate transmission scheme must be selected to span :"I which 
intervening distance. For distances up to 30 ft or so. ",z;  Sjer to be 
ended" drivers and receivers will suffice. For better rchat':: ' l/_grund' 
greater distances, or both, differential signals over a s c: [tit exami 
twisted pair can be used-just as in the transmission mce':'"*B eelvet fa 
of the ring network itself. So, the signal conditioni,g >c;'.'  ; The s 
of the original LNI can be modified to interconnect the l',! trivet be 
and the cable transceiver. , , i ; if the 
4) The Cable Transceiver: The care taken in the dr :;'i deemed 
of a cable transceiver for a contention bus network 'g .0wet, w 
strongly influence the overall reliability and performa )edencest; 
of the network. Therefore, we conclude our case stud? TM Comple 
examining a hypothetical contention bus cable transcc:'"r'- form 
shown in Fig. 8, that is simiIar to one designed and t, udt :t 
the CHAOS Network at the MIT Artificial Intelligence 
tory; it is typical of transceivers built for various c ontcn::' 
bus networks. P: 
The cable transceiver performs the following functions: N 
N 
1) transmission (cable driving); N 
2) reception; T 
3) power and ground isolation; 
4) collision detection; 
5) transceiver fault detection ("watchdog"). 
The first three of these constitute part of the signal 
Ol 
tioning function described previously. exc 
------------------------------<page break>-----------------------------
NOVEi?!:.i, ARK et al.: AN INTRODUCTION TO LOCAL AREA NETWORKS 
.;..'.(?/7-./, basic design principle of the transceiver is that it must 
ob,, ?'5[:".lrresent a high impedenee to the bus except when it is trans- 
'nsmi$si.o '. .itting and actuly driving the bus. This is essential to the 
>r and holated 
referenced to 
one point 
each 
ble via a tap. 
ent to the 
. its host, an 
ected to span 
30 ft or so, '.' 
'or better reliabiltlI. 
.nals over a s 
-ansmission m 
conditionNg 
tterconnect o 
:aken in 
t bus netwo!'/, 
y d perform' 
: our case s'dY 
s cable tm 
:signed and 
. integence'5 
,r vagus conten 
wing function:' 
of the .... 
operation of the contention bus network; a large number of 
", ..e. ceivers on the bus must not present impedence lumps or 
any way interfere with a transceiver which is actively 
nsmitting. 
7he receiver must be able to detect and properly receive 
r4nals from the most distant point on the bus; in addition, 
.: must be able to detect a colliding signal while its companion 
::nsmitter is itself driving the bus. This requirement impacts 
:he choice of an encoding scheme for data transmitted on 
:e bus. A number of data encoding schemes can be used, all 
::' which require that the transmitter be able to place the 
 [ ::ansmission medium in two distinct states. At first glance, 
.: might seem that three states could be used: the quiescent, 
::.-impedence state, to indicate that no transmission is in 
::ogress, and two active driver states, for example +V and 
l'. However, with two active driver states, when two or 
n0re network nodes attempt to transmit simultaneously, 
:he cable will be driven to different voltage levels at different 
:0ints. This has two effects. First, it places a severe load 
:a drivers. Second, it makes the detection of a colliding 
.:gnal more difficult than it needs to be. On the other hand, 
/the transceiver drives the cable to some voltage to represent 
vne signaling state, and represents the other signaling state 
:y not driving the cable, the problem of overloaded drivers 
. eliminated, and the task of collision detection is greatly 
cnplified. Collision detection is accomplished looking at 
:he bus during the transmitter's quiescent state. Any signal 
::esent during that time must come from another transceiver, 
nd constitutes a collision. The transceiver can detect an 
.c0ming signal with 20-dB attenuation, which corresponds 
' about 1 km of the particular cable used. 
the transceiver must be able to cope with ground potential 
:ifferences at the various nel:work hosts. Isolation is accom- 
:lished by high-speed optocouplers and an isolated power 
oply which enables the major circuit elements of the trans- 
:.oer to be referenced to cable ground, rather than local 
:0st ground. Finally, the fault detection, or watchdog 
atcuit examines the output of the driver to guard against 
'ansceiver failures which drive the bus and disrupt the net- 
0rk. The signaling states used by the transceiver result in 
'.qe driver being quiescent approximately 50 percent of the 
'.me; if the driver remains on steadily for several bit-times, 
.: is. deemed to. be faulty, and the fa:lt detector dis.connects 
:i power, which, of co_urse, returns the driver to its high- 
-pedence state. 
5) Complexity of the Local Network Interface.' In its 
:resent form, the LNI omprises about 350 TTL SSI and 
$1 integrated circuits, apportioned as follows: 
PDP-11 full-duplex DMA 100 
Name table controller 25 
Name table cells (8 provided) 90 
Network-oriented portion 120 
Test and diagnostic 15 
Total 350 
he COunt of 120 chips for the network-oriented portion of 
'& LNI, excluding the associative name table, is well within 
1509 
the capabilities of current large-scale integration. As the 
field of local area networking matures, and standards are 
arrived at, it is likely that integrated circuit manufacturers 
will add local area network controllers to their product lines, 
to take their place alongside other LSI data communication 
chips which are already available, making high-performance 
local area network technology available at a very reasonable 
cost. 
V. PROTOCOLS FOR LOCAL AREA NETWORKS 
As in long-haul networks, local area network protocols 
can be divided into two basic levels-low-level protocols 
and high-level protocols. At each level, the characteristics 
of local networks impact effects on protocol design and 
functionality. 
A. Low-Level Protocols 
The term low-level protocol identifies the basic protocols 
used to transport groups of bits through the network with 
appropriate timeliness and reliability. The low-level protocols 
are not aware of the meaning of the bits being transported, 
as distinct from higher level application protocols that use 
the bits to communicate about remote ations. Two aspects 
of local area networks have a very strong impact upon the 
design of low-level protocols. First, the high performance 
achievable purely through hardware technology enables the 
simplification of protocols. Second, low-level protocols 
must be designed to take advantage of and preserve the special 
capabilities of local networks, so that these capabilities can 
be utilized, in turn, by higher level application protocols. 
We will explore these two issues in this section. 
l) Simplicity: Local area networks must support a wide 
variety of hosts, from dedicated microprocessors to large 
time-sharing systems. The existence of extremely simple 
hosts (such as microprocessor-based intelligent terminals, 
or even microprocessor printer controllers) leads to a desire 
for simple, flexible, low-level protocols that can be econom- 
ically implemented on small hosts, while not compromising 
the performance of large hosts. Supporting a variety of hosts 
also leads to a difficult software production and maintenance 
problem that can be ameliorated somewhat by having a. 
protocol that is simple to implement for each new kind of 
host. Although quite a variety of hosts has been attached 
to long-haul networks such as the ARPANET, the problem 
of software development has not been too severe, since each 
individual host in such enviionments usually has:a software 
maintenance and development staff. In the local area network 
context where a variety of computers are all ma/ntained by 
a small programming staff, the arguments for simplicity in 
protocol design are far stronger in our view. 
In a long-haul network, complexity results from strategies 
that attempt to make as much of the costly network band- 
width as possible available for transport of high-level data. 
The costs of a local area network are concentrated instead 
in the host interfaces, the hosts themselves, and their soft- 
ware. Two factors lead to the simplicity of low-level local 
area network protocols. 
a) Unrestricted use of overhead bits: Bandwidth is in- 
expensive in a local area network; there is little motivation 
to be concerned with protocol features designed to reduce 
the size of the header or overhead bits sent with each message. 
This is in contrast to protocols developed for networks making 
the more conventional assumption that bandwidth is expen- 
------------------------------<page break>-----------------------------
1510 PROCEEDINGS OF THE IEEE, VOL. 66, NO. 11, NOVEMBER 19  er al.: A 
sire. For example, the ARPANET NCP host-to-host protocol 
[26] initiates a connection using a 56-bit (net, host, socket) 
identifier for the'destination, but then goes through a nego- 
tiation so that instead of sending this 56-bit value on sub- 
sequent messages, a 32-bit (net, host, link) value can be sent 
instead. It is not clear whether this conservation of bits is 
appropriate even in a long-haul network; in a local area net- 
work, where bandwidth is inexpensive, it is clearly irrelevant. 
Other examples of ways in which extra header space can be 
used to simplify processing include: 
1) having a single standard header format with fields in 
fixed locations, rather than having optional fields or 
multiple packet types; field extraction at the host can 
be optimized, reducing processing time; 
2) using addresses that directly translate into addresses of 
'queues, buffers, port, or processes at i'he' receiver' with- 
out table lookup. 
b} Simplified flow control, etc.: The low transmission 
delay inherent in local area networks, as well as their high 
data rate, can eliminate the need for complex buffer manage- 
ment, flow control, and network congestion control mecha- 
nisms. Consider, for example, flow control: the problem of 
assuring that messages arrive at the recipient at the rate it 
can handle, neither too fast, so that its buffers overflow, nor 
too slow, so that it must wait for the next message after 
processing the previous one, In a long-haul network, a re- 
ceiver typically allocates to the transmitter enough buffer 
space for several messages following the one currently pro- 
cessed by the receiver, so that messages can be placed in 
transit well before the receiver is ready to process them. 
Cons'iderable mechanism is required to keep the sender and 
the receiver properly synchronized under these circumstances. 
In a local area network, the delay will typically be low enough 
for a much simpler flow control mechanism to be employed. 
For example, one can use the very simple strategy of not 
sending a message until the recipient has explicitly indicated, 
by a message in the other direction, that it is ready for it. 
In contrast, a network using communication satellites has 
such a high transmission delay that very complex predictive 
flow control algorithms must be used to obtain reasonable 
data throughput. 
It is crucial to understand that other factors may obviate 
these simplifications. While the data rate and delay char- 
acteristics of a local area network can render it essentially 
instantaneous, its speed cannot eliminate the intrinsic dis- 
parity that may exist between the capabilities of two hosts 
that wish to communicate with each other. These disparities 
may not show up when the two hosts are communicating 
through a long-haul network whose characteristics are so 
constraining that the principal problem is dealing with the 
restrictions of the network. While protocols for local area 
networks need not include mechanisms designed to cope 
with the limitations of the network itself, it is still necessary 
to design protocols with sufficient generality to cope with 
disparities between the capabilities of machines wishing to 
communicate through the network. Such disparities include: 
1) mismatch between the rate at which hosts can generate 
and absorb data; 
2) host delay between the time a packet is received and the 
time it is successfully processed and acknowledged: 
3) amount of buffer space available at the sender and the 
receiver. 
Fig. 9. The urgent pointer mechanism. By transmitting a new. 
value of the urgent pointer, a pointer into the data stream, a 
can indicate the data bufferred in the sender, network, and 
are holding up data that must be processed quickly. Therecciv.r 
then adjust his use of the data stream flow control to proccs 
bufferred data until the urgent data'is processed. The shaded aru 
dicates the location of potentially urgent data specified by a patticub: 
.urgent pointer value. 
Further, considerable effort may be required to modify, 
software to provide a suitable interface to the network. 
one were to consider the simple flow control mecharn,:i: 
mentioned earlier, where a message is sent in the 
direction requesting transmission of each message as t 
needed, one would discover that in many cases the scheme 
was unworkable, not because the network introduced inn '. 
erable delays, but because the hosts communicating 
each other themselves introduced excessive delay. In a 
host with a time-shared operating system, for example. 
real time that elapses from the time a message is recci,c,: 
one or more processes are scheduled in response to this 
sage, and that pro.cess runs, to the time a message is scnl 
response, could well run into a large number of 
milliseconds during which the other host is forced to wait. 
c} Example of protocol simplification: The 1ow-lc: 
protocol initially proposed for the Laboratory for Computer 
Science Network at MIT is an example of the sort ofproto,',': 
that results when simplicity of mechanism is a primary 
goal. The Data Stream Protocol (DSP) was based on 
Transmission Control Protocol (TCP) used in internetworkr..: 
experiments sponsored by the Defense Advanced Rcsca:.> 
Projects Agency [27], but evolved from original TCP duc t- 
the continuing desire to simplify the protocol features. 
formats, and implementation strategies. Most of these 
fications have subsequently been incorporated into the T(T 
One specific example is the mechanism used to signal 
rupts and other urgent messages that are logically part or' 
sequence of data in a virtual circuit. The basic model is 
the sender occasionally wants to signal the receiver that f' 
data in the stream preceding the signal (buffered sornehc: 
in the network) must be scanned immediately in order 
respond promptly to some other important signal. A moths 
nism is provided whereby a pointer into the data stream 
maintained at the receiver, which can be moved, when 
sender chooses, to point to a more recently transmitre-' 
piece of data. This pointer, called the urgent pointer. 
be used to indicate the point in the data stream beyond 
there is no more urgent data. (See Fig. 9.) The urgent pointe: 
can be implemented in two ways, depending upon the 
of the host receiving the message. In the case of a si mt 
(e.g., microprocessor) host dedicated to a task that proCs:o 
the incoming stream as it arrives, the host need not 
the urgent pointer, since by design, all data, urgent or not. 
are processed as quickly as possible. In contrast, on a 
time-shared host,' data need not be processed until eilhS 
process 
or b) t] 
by th 
)cessed 
mech 
erstandi 
data str 
in its part: 
[s a simpl 
:' host im 
, on unso 
for lc 
protc 
to 
Co 
bet 
ween t 
cir 
dell' 
circuit i 
easily p 
of co 
where t 
of a 
and 
not to 
poten 
Message 
is the 
pr 
numbe: 
net, it i 
giving 
is made 
table wi 
to rr 
the n: 
address. 
is n 
:large num 
exchan 
of such 
form, 
it is 
Broadca. 
for a 
. is intend 
we fin 
is ,to 
then 
of such 
There ar 
netw( 
to th( 
annoul 
disc 
imple 
as docu 
and x 
------------------------------<page break>-----------------------------
ins a new, 
stream, a  
)rk, and re.ac, 
The r ecelm,t 
.1 to proceaa 
e shaded ea 
d by a pa 
modify 
network. 
 ol mechaalta 
in the 
:ssage as it 
es the scha 
reduced iatol- 
nicating 
!.RK et al.: AN INTRODUCTION TO LOCAL AREA NETWORKS 
the process to receive the data is scheduled and requests 
at, or b) the urgent pointer points to data not already 
eived by the process. In case b) an interrupt is sent to 
receiving process, indicating that data should be read 
:5 processed- until the urgent pointer is past. The corre- 
Nnding mechanism in TCP required that a host be capable 
understanding and responding to a special interrupt signal 
the data stream, even if the signal had no meaning to the 
:st in its particular application of TCP. The urgent pointer, 
::n, is a simple mechanism that meets the needs of sophistJ- 
ared host implementations without placing an excessive 
.;rden on unsophisticated hosts. 
:) Special Capabilities: The other aspect of low-level 
..0tocols for local area networks to be discussed is the manner 
:vhich protocols must be structured to take advantage of, 
:j provide to higher levels, the unique capabilities of local 
:::vorks. Conventional low-level protocols have provided 
/unction best characterized as a bidirectional stream of 
 .:s between two communicating entities-a virtual circuit. 
2e v/rtual circuit is implemented by a process that provides 
:4uenccd delivery of packets at the destination. While a 
:ual circuit is one important form of communication, two 
'.,.ers easily provided by a local network are very useful in 
uriety of contexts. These are message exchange communi- 
ci0n, where the packets exchanged are not viewed as being 
::rnbers of a sequence of packets but are rather isolated 
ay. In a 1._ a:t:hanges, and broadcast communication in wtdch messages 
example, th :: sent not to one particular recipient but to a selected sub- 
ge is receiod. 
;e to thi ram. 
sage is sent 
[ milliseconaL 
d to wait, 
['he low-ltd 
for Compui 
,rt of protocol 
rimary de, 
based on 
ternetworkiu{ 
.ced Rseatd 
fi TCP due t 
atures, packel 
f these simpli, 
to the TCPo 
o signal 
ly o5 
model 
:civet 
d soraewhm 
, in 
el. 
ata 
ed, wh on:llm 
, transmittal 
pointer}'C 
>eyerid 
)n the 
of a 
hat po 
i not p..[,l.. 
rgent o(i. 
st on 
:: of the potential recipients on the network. 
a) Message exchange: A typical example of a message 
::hange is the situation in which one message asks a question 
: another provides the answer. For example, if there are 
'.rge number of services provided by nodes connected to 
local net, it is disadvantageous to maintain, on every node, 
'. rabte giving all of the addresses of these, for whenever a 
unge is made in the network address of any service, every 
.de's table will need to be revised. Rather, it may be ad- 
ntageous to maintain, as a network service, a facility wkich 
:,'g take the name of a desired entity and give back its net- 
!,rk address. Clearly, the pattern of communication with 
: service is not one of opening a connection and exchang- 
!ga large number of messages, but instead is a simple two- 
,::sage exchange, with a query of the form "What is the 
'clress of such and such a service?" and a reply of similarly 
!nple form. While a virtual circuit could be used for this 
.i:ange,.it is'unneded.gnrl uses. excessive resources. '. - ' 
 )Broadcast: The exanlple given above demonstrates 
:: need for a broadcast mechanism. If the service described 
 '..)re is intended to provide .the address of network services, 
:w can we find the address of this service itself?. An obvious 
F-:ution is to broadcast the request for information. The 
l::.'ry then takes the form "Would anyone who knows the 
].lress of such and such a network service please send it to 
,". There are many other examples, some apparently trivial 
!' nonetheless very useful, for support of broadcast queries 
 local network. A microprocessor with no calendar clock 
h.v broadcast a request for the time of day. A new host 
Cached to the network for the first time may broadcast a 
%age announcing its presence, so that those who maintain 
les may discover its existence and record'the fact. Broad- 
q raechanisms in the low-level protocols can also be quite 
ul in implementing higher level protocols for such appli- 
.:0ns as document distribution to multiple host nodes, and 
'4sPeech and video conference calls. 
1511 
Why are these alternative models of communication not 
commonly found in traditional networks? The first, and 
perhaps most important reason is that long-haul networks 
have not been extensively exploited for applications in which 
computers directly query other computers with individual, 
self-contained queries. Instead, the major use of long-haul 
networks has been for long-term, human-initiated interactions 
with computers, such as direct terminal use of a remote 
computer, or long-term attachments of remote job entry 
stations. Such human interactions usually involve many 
message exchanges between sender and receiver, so that the 
extra delay and cost of initial setup of a virtual circuit is 
insignificant-perhaps even recovered by reducing redundant 
information in each message. As new applications such as 
distributed data base systems become more important, these 
alternative models will become important in long-haul net- 
works, but long-lived connections between terminals and 
host computers continue to dominate the usage. 
The second reason is precisely that discussed in the previous 
section concerning the relative simplicity of protocols for 
local area networks-a variety of functions performed in con- 
ventional networks are very difficult to understand except in 
the context of a sequence of ordered messages (a virtual 
circuit) exchanged between two nodes. .For example, flow 
control is normally handled in network protocols by placing 
an upper bound on the number of messages which may be 
flowing at any one time between the sender and the receiver. 
This concept has meaning only in the restricted case where 
the sender and the receiver are a well-identified pair exchang- 
ing a sequence of messages. There is no obvious equivalent 
of flow control that can be applied to situations where sender 
and receiver communicate by sending arbitrary unsequenced 
messages, or where a sender broadcasts to several receivers. 
Similarly, if efficiency requires use of the shorthand version 
of an address for communication between the sender and 
the receiver, this clearly iraplies that the sender and the 
receiver have. negotiated this address, and agree to use it 
over some sequence of messages. Again, this idea makes no 
sense if communication is isolated in unsequenced messages. 
Another problem that is traditionally handled in the con- 
text of a sequence of messages is the acknowledgment to the 
sender that the receiver has correctly received a message. If 
messages are sequenced, acknowledgment can be very easily 
done by acknowledging the highest member of the sequence 
that has been successfully. received. If messages bear .no 
relatiOn}hip 'to each othe, ihen 6ach must be identified 
uniquely by the sender, and acknowledged uniquely by the 
receiver. This .increases the complexity and overhead of 
acknowledgment. However, in most cases where message 
exchange communication is the appropriate underlying com- 
munication model, no acknowledgment mechanism is required 
of the low-level protocol at all. For example, if a micropro- 
cessor system asks the time of day, it is not at aU necessary 
to acknowledge that the query has been successfully received; 
the receipt of the correct time is sufficient acknowledgment. 
Similarly, a request for a network address is acknowledged by 
a return message that contains the desired address. Depend- 
ing on a low-level acknowledgment message to handle all 
failures can be dangerous, for it may lead to the practice 
of assuming that acknowledgment of receipt of a message 
implies that the message was processed at a high level. 
In the broadcast context, it is difficult to formulate a use- 
ful definition of acknowledgment that can .be supported by 
a low-level protocol. What does it mean to say that a broad- 
------------------------------<page break>-----------------------------
1512 
PROCEEDINGS OF THE IEEE, VOL. 66, NO. 11, NOVEMBER 
et al.: A. 
cast message has been successfully received? By one of the 
possible recipients? By all of the possible recipients? One 
appropriate strategy is to rely on the high-level application 
to deal with these problems as a part of its normal operation, 
rather than have the low-level protocol concern itself with 
issues of flow control or acknowledgment at all. 
3} Protocol Structure: Based on the previous observations, 
a two-layer structure is a very natural one for low-level pro- 
tocols in a local area network. The bottom layer should 
provide the basic function of delivering an addressed message 
to its (one or many) destinations. This level corresponds 
to the concept of a datagram network [28]. It should also 
take on the responsibility of detecting that a message has 
been damaged in transit. To this end it may append a 
checksum to a message and verify the checksum on receipt. 
.However, t.his .layer. proba.bly should not take o .the..respon- 
sibility of ensuring that messages are delivered, hnd delivered 
in the order sent, since different applications have different 
needs and requirements for these functions. The first layer 
might be implemented entirely in hardware; however, if the 
packet size, addressing structure, or routing topology of the 
hardware is not sufficient to provide adequate message size, 
process addressing, or broadcast selectivity, some software 
help will be needed to make up the difference. 
Above this first layer should be made available a variety 
of protocols. One protocol should support a virtual circuit 
mechanism, since a virtual circuit is definitely the appropriate 
model for a great deal of the communication that will go on 
in any network, local or otherwise. As alternatives to the 
virtual circuit protocol, there should be mechanisms for 
sending isolated messages, for message exchange communi- 
cation, and additional alternatives to provide support for 
message models other than the ones we have discussed here. 
For example, transmission of digitized speech requires a 
communication model with some but not all of the attributes 
of the virtual circuit; in particular, reliability is of less con- 
cern than timeliness of arrival. 
B. Applications of Local Area Networks; Higher Level 
Protocols 
In the pevious section we considered low-level protocols 
for a local area network. These protocols exist, of course, 
to support higher level protocols, which, in turn, support user 
applications. In this section we ,,ill consider a number of 
applications for which local area net.works are suited. 
1} Access to Common Resources: The model of computing 
most common over the last few years is that of a large cen- 
tralized computer, with the only remote components being 
terminals and, perhaps, a few other I/O devices. Line control 
protocols such as SDLC [19] were created to serve this sort of 
arrangement. A simple but very important application of a 
local area network is to generalize this picture very slightly 
to include more than one central computer. As the total 
workload grows to exceed the capacity of a single machine, 
a common solution is to procure a second machine, and to 
'divide the applications and workload between the two. The 
communication problem to be solved in this arrangement is 
simple but critical-to allow an individual terminal to have 
access to both of the central machines. A local area network 
can solve this problem, and provide some additional capa- 
bilities as well. For example, if the central facility has special- 
ized I/O devices such as plotters or microfilm writers, they 
can be placed on the local area network and made acccshlr 
to both central machines-an advantage if a device is expcnm: 
and is not heavily enough loaded to justify having one 
each computer. Further, 1/O devices can be placed 
from the central site but convenient to users; for exampl: 
a line printer. can be placed near a cluster of users. 
This pattern of sharing among several computers can 
expanded to include more than just I/O devices. In fat: 
the network can be used to move computations from 
machine to another in order to spread the computing 
equally. The high speeds available in the local area 
make this sort of load leveling much more practical than 
the bandwidths traditionally available on long-haul netw(:rk 
2) Decentralized Computing: A wide variety of new 
for a local area network arises if the computing power 
able is not strongly.centralizel...Le.t us consider the alternator 
o{ a computing environment consisting of a large number 
relatively small machines, each dedicated to a small numbc.. 
of users or a small number of tasks. In the extreme, wc 
look to the future and imagine the day when each user 
a computer on his desk instead of a terminal. Such ; 
pletely distributed computing environment by no 
eliminates the need for an interconnecting network. 
users will still need to exchange information. Data 
containing the results of one person's computation will nee: 
to be shipped through the local area network to be 
input to other tasks. Users will wish to communicate 
each other by exchanging computer mail, as is now 
over the ARPANET [29]. Users will still want accc.x 
specialized resources which cannot be provided to each 
resources such as large archival storage systems, Spcciahtr,' 
output devices such as photo typesetters, or conncct;o.'. 
points to long-haul networks. All of these features can 
made available through the local area network. 
3} Protocol and Operating System Support: The apph,a 
tions outlined in the previous paragraph can be suppor:c': 
by high-level protocols very similar to the ones alread. 
existence in the ARPANET: TELNET for logging into 
remote system through the network, and File Transfer ?:.' 
tocol for exchanging data between machines [26]. When ,"" 
examines how these protocols might be modified to 
advantage of the special attributes of a local area not 
for example, its higher speed, one discovers that the problc. 
is not one of modifying the protocols, but of modifying 
operating system of the hosts connected to the network 
that the services available through the network appear 
a natural part of the programming environment of the 
sting system. The File Transfer Protocol in the ARPAS} 
for example, is usually made available to th user as an 
command which he may invoke to move a file from 
machine to another. As part of this invocation he tnay - 
required to identify himself at the other machine, and 
explicit file names in the syntax of the local and the fo 
machine, describing exactly what action he wishes to perfo 
This particular view of file transfer has two di sadvantat's 
First, there is a lot of overhead associated with moving a 
Much of the delay in moving the file seen by the user.  
nothing to do with the time required to send the dtba)hs 
through the network, but is rather the time spent est 
the connection, identifying the user at the other site. 
Second, the file system on the local computer undertSt 
nothing about the existence of files accessible throU 
network. No matter how sophisticated the local file $yaC 
terms of' 
it 
througl. 
The 
 
rare obvi 
on the 
integ: 
and use 
syster 
mat 
Som 
of 
whict 
in the 
[ 
design 
of t 
ithe curre: 
syste 
into t? 
[311,  
[ 
INTERC 
was menti 
of the o, 
to it. 
to prov: 
local area: 
ad' 
cost, b 
to a 
of con: 
one c: 
local a 
)tocol Co/ 
are tw 
the in 
aul netw 
cannr 
can. 
the 
the p 
only tl 
and n 
area net 
netw 
the p 
Fe 
area n 
the loc 
area 
------------------------------<page break>-----------------------------
ice is expeiidvt 
placed 
,; for e 
pute 
'ions from 
:ompug 
 area uetw 
'acti t 
taul netwo 
ty of new 
ng pow 
r the 
arge n 
 sm n 
xtreme, we 
a eack 
1. Such a 
by no 
; network, 
n. Data 
tation 
 to be 
 Is flow 
ed to eac 
eros, sp 
or 
featu 
,t: The appll 
n-be supporte 
ones already 
logging into 
2,1iK et al.: AN INTRODUCTION TO LOCAL AREA NETWORKS 
 in terms of keeping track of the various files that the user 
ges about, it requires explicit user intervention in order to 
:ach through the network and retrieve a file from another 
.actline. The use of a high-speed local area network will 
t eliminate any of these problems, but will instead make 
aa more obvious to the user the overhead that the protocol 
lloses on the transfer of data. Clearly, what is needed is 
! further integration of the local area network into the file 
.,tem and user authentication mechanism of the individual 
:0,rating systems, so that interchange of information between 
i'- various machines can he done with less direct user inter- 
..ntion. Some attempts have been made to do this within 
:e context of the ARPANET. RSEXEC is an example of a 
.0tocol which makes files on various TENEX operating 
 .stems in the ARPANET appear to the user to exist on a 
gle machine [30]. 
[he design of operating system structures to take full 
;.antage of the capabilities of local area networks repre- 
,t$ the current edge of research in this area. Examples of 
.erating systems that incorporate a high-speed local area 
:;twork into their architecture are the Distributed Computing 
 ,stem [31 ], the Distributed Loop Operating System [ I 11, 
.._3 ININET [32]. 
V'[. INTERCONNECTION OF LOCAL AREA NETWORKS 
WITH OTHER NETWORKS 
t Motivation ]'or Interconnection 
.B was mentioned earlier, a local area network will be only 
.7art of the overall communication system used by the hosts 
'ztached to it. A very important use of the local area network 
,a be to provide an interconnection between hosts attached 
: a local area network and other networks such as long-haul 
cket-switched networks and point-to-point transmission 
 zks. The advantage of this method of interconnection is 
:Juced cost, by taking advantage of the fact that connection 
a host to a local area network is relatively inexpensive. 
 tead of connecting all machines directly to the long-haul 
2e Transfcrlh' ::tork, one can connect all the host computers to the local 
[26]. Wheao l:u network, with one machine, the gateway, connected to 
odified to  ,:lh the local area network and the long-haul network. 
al area nctwo ! ' 
.hat the probk ! Protocol Compatibility 
>f modifyis. *tl 
the netw0  
0rk appear,t-. 
the A' . 
ser   e 
a file fs 
ation he 
ld 
go 
ith 
by th0 
nd the 
spent 
= other 
mter 
;iblo 
: loc 
hem are two pitfalls that should be avoided when plan- 
. for the interconnection of a local area network with a 
:al-haul network. On the.one hand, long-haul networks 
':nently cannot' provide all_ of tlie functions that local area 
orks can. If a local area network is initially designed to 
*'e only the function of connecting hosts to a long-haul 
-ork, the protocols of the local network may be designed 
. serve only the needs of communicating with the long-haul 
ork, and may not support the other functions that make 
'.0cal area network especially attractive. On the other hand, 
 local network is initially designed with no thought given 
the possibility that it may be interconnected with another 
the protocols designed for it may lack the necessary 
For example, the addressing structure used on 
local area network may not be able to express destinations 
the local network. In either case, the only after-the- 
solution is to implement a second set of protocols for 
area network, so that different protocols are used 
totercommunication with long-haul networks and for 
services. This proliferation of protocols is undesirable, 
1513 
as it adds to the cost of software development as}ociated 
with each new host added to the local area network. To 
avoid these pitfalls, it is important that all the functions a 
local area network is to provide must be considered from 
the very inception of the design of the network, and the 
protocols for the network must be designed to support that 
entire range of functionality. 
Fortunately, initial experiments with protocols for local 
area networks suggest that a uniform approach to protocol 
design can support both specialized local network functions 
and interconnection with other networks, provided that both 
functions are envisioned from the start. Although the pro- 
tocols used in the local area network must be made slightly 
more general to handle the internetworking situation, there 
is no interference with the realization of the purely local 
network functions. For example, a more general address 
field must be used to specify the destination of a message, 
but the only overhead implied if this same addressing struc- 
ture is used for purely local messages is additional bits in 
the message to hold a presumably larger address. Since band- 
width is inexpensive, the bits "wasted" on this larger address 
are presumably irrelevant. 
A slightly more difficult problem, one that is still being 
studied, is the problem of speed matching between the local 
area network and the long-haul network. As this paper has 
characterized the difference between local nets and long-haul 
nets, it is reasonable to presume that the local network will 
have a much higher data rate. If a host sends a large number 
of packets into the local area network with an ultimate des- 
tination to be reached through the long-haul network, the 
packets may arrive at the gateway much faster then the 
gateway can pass them to the long-haul network. Some 
mechanism will be required to prevent the gateway from 
exhausting its buffer space. The speed matching problem 
is not unique to the gateway between the local area network 
and the long-haul network; it occurs any time two networks 
of differing speed are connected together. (The problem may 
be more extreme here, though, due to the greater speed dif- 
ference that can be encountered between local area and some 
long-haul networks. SatelLite networks with speeds com- 
parible to local networks are quite conceivable, yet are a 
long-haul technology.) A general discussion of the problems 
of internetworking, and some proposed solutions can be 
found in a companion paper by Cerf and Kirstein in this 
issue [33]. 
At the nekt highe. r level of protocol,'one fin'ds facilities that 
support various communications models, such as virtual 
circuits, broadcast, and message exchange. In interconnecting 
to a long-haul network we are chiefly forced to deal with a 
virtual circuit model, since that is the only pattern of com- 
munication usually supported by commercial long-haul 
networks. Here, it is appropriate to use a virtual circuit pro- 
tocol in the local area network as similar as possible to that 
used in the long-haul network, so that translation between 
the two is easy. Although there is not as much practical 
experience available in the area of network interconnection 
as could be desired, it appears that one can develop a virtual 
circuit protocol for a local area network that is a compatible 
subset (in the sense of using compatible packet formats and 
control algorithms) of a suitable long-haul virtual circuit 
protocol. This means that it is not necessary to implement 
two complete virtual circuit protocols, one for internal local 
network use and the other for communication out through 
------------------------------<page break>-----------------------------
1514 
the local net. It leaves unanswered the question of how the 
additional features, such as complex flow ont.ol, buffering, 
and speed matching required for the long-haul protocol should 
be implemented. One approach would be to implement them 
in every host that desires to communicate over the long-haul 
network; this implies a programming burden for every ma- 
chine. An alternative would be to implement the additional 
functions in the gateway machine that intemonnects the local 
area network to the long-haul network. This would add 
considerable complexity to the gateway, for it will have to 
cope with such problems as the speed differential between 
the two networks without having the benefit of the flow 
control mechanisms normally used for this purpose in the 
long-haul network. At this time, it is not clear whether the 
gateway can assume the entire responsibility for augmenting 
.a local netw.ork virtual circuit protocol' with. the' functions 
required for communication through a long-haul network. 
It would be advantageous to make sure the local area net- 
work protocols are also compatible with other communica- 
tion models, such as single message exchange or selective 
broadcast, that may become available on commercial long-haul 
networks in the future. However, this presupposes that the 
long-haul networks attached to the local area network use 
a two-layer low-level protocol implementation such as that 
described for the local area network, and if the long-haul 
networks do use such an implementation, that they provide 
an interface that allows direct-use of the datagram layer. 
Many current long-haul networks do not provide that interface. 
VII. THE SUBNETWORK CONCEPT 
Resting midway between the monolithic, single-technology, 
local area network and the internetworking environment is an 
approach to local area networking that we term the subnet- 
work concept, which provides for a mix of network technol- 
ogies within a uniform addressing and administrative structure. 
,4. General ,4pproach 
A local area network can be composed of a collection of 
subnetworks, possibly implemented with various network 
technologies and perhaps with various transmission rates, but 
using identical software protocols, compatible packet sizes, 
and a single overall homogeneous address spaceil These 
subnetworks are interconnected by bridges, which are midway 
in complexity between the repedters used in a multisegment 
contention bus network (ETHER-NET) and the gateway pro- 
cessor used between networks in an internetworking environ- 
ment. This general structure is indicated in Fig. 10. A bridge 
links two subnetworks, generally at a location at which they 
are physically adjacent, and selectively repeats packets from 
each of them to the other, according to a "filter function. "6 
In addition, since they buffer the packets they repeat, they 
can perform a speed-matching function as well. 
B. Advantages of Subnetworking 
The subnetworking concept enables a variety of technologies 
and data rates to be utilized in a single local area network, 
each to its best advantage. For example, a network could 
SThe subnetwork concept, as we describe it, is a generalization of 
an approach suggested by Pierce [5] for use with multiple loops or 
rings. 
eThe concept of the filter function is introduced in the "filtering 
repeaters" described by Boggs and Metcalfe { 141. 
PROCEEDINGS OF THE IEEE, VOL. 66, NO. I 1, NOVEMBER 1971 
et 1.: A 
i bnetwr 
work.  
aneous  
l' offered 
ty of the 
tcnnects s 
0 r subnet 
Ifver, if the 
Ihe targe 
d packets 
Iarea netwc 
p'ckets. 
nsparenc 
ubnetwc 
ent, bo! 
I. "outside 
I..'twork m 
have no k. 
'.work, in 
ltion hos 
..o. the r sub. 
I,i by one 
Wlckets ar 
l;nply addr 
,up by a 
I?ion bet, 
I,rking, wit 
a'as reit a p: 
d is on 
l't the n- 
...ro te gatt 
ns, if. 
len transv. 
tworking, 
WCket size 
II_a- nor flag 
li mention 
host 
1 area ne 
Fig. 10. The subnetwork concept. Here, a local area network i c,,m 
posed of a number of subnetworks, linked in some fashion b:,' bridit 
The subnetworks, though of differing technologies, share one addt,. 
space, and the same protocols are used over the entire network: 
the bridges can be simpler ttian'the gaieay which'c'onnects h 
area network to the long-haul network. Viewed externally, from 
side the dashed line in the figure, the local area network appean ,, 
monolithic. 
be constructed with a contention bus subnetwork. perh:r, 
using coaxial cable originally installed for CATV, anti I 
ring subnetwork, using twisted pair which can be casdy 
stalled in a crowded laboratory environment. These two 
networks could be of different data rates; the bridge bctv, c.-. 
the two will handle the speed difference between them. 
Subnetworking 'also provides an orderly means for 
growth in traffic. Local area networks perform best, 
high throughput with low delay, when they are not 
loaded. As traffic on a local area network grows with 
if a higher speed technology is not available, it may bc 
able to split the network into two or more interconnect.',: 
subnetworks. Since the bridges wkich interconnect 
subnetworks are selective in their repeating of packets 
the bridge," not all packets from a subnetwork will flo,, '.' 
all other subnetworks, and the traffic density on each 
network will be less than that of the original monolithic 
work. If the partitioning of the hosts into subnetworks ,: 
be done along the lines of "communities of interest." 
that a group of hosts with high traffic rates among them,c:, ." 
but with substantially lower traffic rates to other ho,t, 
placed in the same subnetwork, traffic across the bridge* 
be minimized, and a greater fraction of all packets x11 
within their subnetwork of origin. 
C. Bridges 
A bridge, depicted in Fig. 11, contains: 
two network interfaces, one appropriate to each of the :": 
subnetworks it interconnects, 
a limited amount of packet buffer memory, and 
a control element, which implements an appropriate ::"" 
function to decide which messages to "pull off" one *:"' 
network and buffer until it has an opportunity to 
mir it to the other subnetwork. 
The topology of the subnetworks interconnected by  
determines the complexity of its filter function. .4 
with a simple filter function can be implemented using a f' :t on N 
state machine as its control element; a complex filter f unct""a' 
which may involve a periodic exchange of information atn,', a Io 
bridges on the network to determine correct routing. a the ' 
f View o 
require the capabilities of a microprocessor [34].  rno.a 
A bridge must buffer packets since, upon receiwng er. 
from one subnetwork which it decides to repeat to the oor not 
way 
------------------------------<page break>-----------------------------
tEiSffi''_s&JsRK et aI:AN INTRODUCTION TO LOCAL AREA NETWORKS 
,.o;9..!l,:v.  
  LI. The structure of a bridge. A bridge would most aturally be 
 cated at a point where the two subnetwor it interconnects have 
 en tade physically adjacent. 
.network, it must wt for an oppounity to transmit on 
etwork   :I subnetwork, according to the control structure of that 
hion by b 
ona -5netwrk' Packet buffers also aid a bridge in handling 
nor .antaneous cross-bridge traffic peaks during wch the 
mneetsth ;ific offered by one subnetwork exceeds the available 
'n,from, ,city of the other. This situation can ase if the bridge 
rk appe to  ' 
::rconnects subnetworks of dissimilar data transmission 
::s, m' subnetworks of drastically different traffic densities. 
?,ever, if the sustained cross-bridge traffic offered is greater 
: the target subnetwork can handle, the bridge must 
.card packets. This is an acceptable course of action, as 
 21 area network protocols are generally prepared o handle 
 packets. 
work, perh 
'V, and with 
a be easily b. 
Fhese two 
3ridge btwc 
a them. 
as flor 
e not h 
ows wi 
t may be  
inteonn 
terconn 
packets 
rk w flo 
y on ch b 
monoStc 
ubnetwor 
intert,"  
nong them 
other 
the bridge'. 
ackets  
. ?ransparency 
{ [he subnetwork structure of a local area network should be 
.sparent, both to the hosts on the local area network and 
the "outside world"-other networks to which the local 
::a network may be connected via gateways. A host on the 
cal area network wishing to transmit a packet to another 
. d have no knowledge of whether that host is on the same 
.?network, in which case the packet will be received by the 
:;lination host directly, or whether the destination host is 
: another subnetwork, in which case the packet is retrans- 
':ed by one or more bridges. In particular, no ordinary 
'.:a packets are ever addressed to a bridge; rather, packets 
:: simpl addressed to their destination hosts, and may be 
(';ked up by a bridge and passed along through other sub- 
:f"*'0rks, finally reaching their destinations. This is a key 
inction between subnetworking, with bridges, and inter- 
 ::''0rkg, with gateways: in internetworng, a host about 
 ,ansmit a packet must realize that the host to which it is 
i&essed is on a different network. The sending host must 
....,.. :csmit he 'mege in a loc network "wrapper" to an 
 _ ' :;x0pate gateway; wc.'unwraps" it, performs protoco 
-,.,.'i(, .'ersions, if any, packet agmentation, etc., as necessa, 
":' ' I ' ' 
 ..., - hen transmits the meage into the other network. In 
and , .-,', , , - 
'at6  .etworing, protocols ar identical over all subnetworks, 
P: '' iP0acket sizes are compatible, so that neither protocol con- 
.  t-, n nor fragmentation takes place in the bridges. Finally, 
tunity o , -- 
.,/. 'as mentioned above, a packet is directly addressed to its 
:'::'':  host, not to a bridge, for hosts do not know tkat 
.ected 
rotion. ' 
ated 
ex 
ect 
341. 
eceiving 
:peat 
area network is composed of subnetworks. 
Impact on Network Characteristics 
Ptitting a local area network into subnetworks has little 
on th.e, key characteristics of the network. From the 
of v:ew of the users and hosts of the network, address- 
 affected only slightly, if at all. Bridges must determine 
or not a packet should be picked up for retransmis- 
way to aid bridges in this determination is to include 
1515 
a subnetwork field in the address of each host. Other routing 
techniques which have no impact at all on addressing (such as 
complete table look-up of host addresses by the bridges) can 
be implemented, although usually at the expense of greater 
complexity within the bridges. 
Splitting a local area network into subnetworks should have 
no effect on the protocols of the network. One exception 
is if a particular subnetwork technology provides a hardware 
acknowledgment of delivery of a packet (as in the DCS Ring 
Network) [2]; this acknowledgment may only indicate suc- 
cessful receipt by a bridge. However, not all network tech- 
nologies provide hardware acknowledgments, and, in a net- 
work of mixed technologies, host-to-host acknowledgments 
will generally be provided by software protocols. Traffic is, 
of course, affected by subnetworking in a positive way. 
Splitting a local area network into subnetworks in a judicious 
way can minimize the overall traffic of the network; bottle- 
necks can be eliminated by using higher bandwidth tech- 
nologies for affected subnetworks. 
F. The Long-Distance Bridge 
There are situations in which it is necessary to interconnect 
two subnetworks of a local area network which cannot be 
brought physically adjacent to one another so that an ordinary 
bridge may be connected between them. An example of 
this would be a local area network on a university campus, 
with a major research laboratory across town. The laboratory 
may be beyond the range of a twisted-pair ring network or 
a coaxial cable contention bus network; or it may be within 
range, but it may be irapossible for the university to install 
its own cables between them. ? The off campus research lab- 
oratory can be given its own subnetwork, connected to the 
main campus subnetwork via a specialized long-distance 
bridge. 
A long-distance bridge is made tip of two half-bridges at 
either end of a suitable full-duplex point-to-point communi- 
cation link, such as a high-bandwidth common carrier circuit, 
an optical link, or a private microwave link (Fig. 1 2). Some 
other network technology such as packet radio could be used 
to derive this point-to-point link as desired. s Each half-bridge 
contains an appropriate interface to its subnetwork, packet 
buffers, and a controller. In addition to its filtering function, 
the controller of a half-bridge regulates the flow of data over 
the communication link between the two halves of the bridge. 
Of course, 'it is possible' that .the bridge communication li.nk 
may' be of lower bandwidth than the two subnetworks' it 
interconnects. Additional packet buffers at each half-bridge 
can help to smoothe out traffic peaks, but if the communi- 
cation link is a bottleneck, the long-distance bridge must 
discard packets just as an ordinary bridge does when it is 
overloaded. 9 
Although common carriers such as the Bell System operating com- 
panies are moving in the direction of leasing wire pairs for transmission 
of digital signals with customer-provided equipment, these circuits are 
not intended for use at the high bandwidth of local area networks, 
and are generally routed through central offices rather than point-to- 
point. 
SAlthough we do not discuss it further in this paper, there is an 
interesting philosophical issue whether the intervening network should 
be viewed in the internetworking context using gateways or as a point- 
to-point link within a singlebridge. 
If the bottleneck created by the communication link of a long 
bridge is severe, the local area network advantages of high-bandwidth 
communication with low delay will be forfeited. 
------------------------------<page break>-----------------------------
1516 
" Cornrnunicohon Link 
Fig. 12. The "long bradgr." In this case. the two subnetworks cannot 
be made physically adjacent, so a half-bridge is attached to each, and 
a full-duplex communication link is employed to interconnect the 
two half-bridges. The control and filter functions, and the packet 
buffers, are replicated in each half-bridge. 
VIII. CONCLUSION 
The utilization of a technological innovation often occurs 
in two stages. In the first stage, the innovation is exploited 
to perform better the same tasks that were already being 
performed. In the second stage, new applications are dis- 
covered, which could not be reasonably performed or even 
forseen prior to the innovation. Local area networks are now 
on the threshold of this second stage. While there is still much 
room for creativity i improving the innovation itself-reducing 
the cost of the network interface and increasing its speed and 
convenience-the real challenge lies in identifying new sorts 
of applications that a local area network can make possible 
Current trends /n hardware costs encourage abandoment of 
a single large computer in favor of a number of smaller ma- 
chines. This decentralization of computing power is, for 
many applications. a natural an'd obvious pattern. In many 
information processing applications, for example, the infor- 
mation itself is distributed in nature, and can most appro- 
priately be managed by distributed machines. Distributed 
applications can only be constructed, however, if it is possible 
to link their machines together in an effective manner. Subject 
to their geographical limitations, local area networks offer 
a very effective ad inexpensive way to provide titis inter- 
connection. The yeatest impact of local area networks will 
come with the development of operating systems that inte- 
grate the idea of distribution and communication at a fun- 
damental level. 
The impact of local area networks on the decentralization 
of computing is sociological' as well as technological. Oper- 
ational control of centralized computers has traditionally 
been vested in the staff of a computer center. The trend 
toward decentralized computing greatly increases the au- 
tonomy. of individual managers in the operation of their 
PROCEEDINGS OF THE IEEE, VOL. 66, NO. I 1, NOVEMBER 
machines, and appears to reduce the need for a ccntrd 
staff of computer managers. The communication capab.. 
made available by local area networks will serve to brad 
decentralized maciffnes together into a unified inforrnt.,, 
processing resource. The effectiveness of tiffs resource 
be measured by the degree of coherence it achieves. 
in turn, depends upon the care and foresight put inlo 
design of the local area network and the developmen,, 
standards for communication at all levels. It is in the 
fication of areas in which standards are needed, and m t.%., 
development, that the staff of the "computer cctu.:" ,, 
future will find its work. 
REFERENCES 
[ I ]. I'. J.' Father nd K C. Larson, "The system archlleclure 
distributed computer system--The communicatims 
presented at the Symposium on Computer 
technic Institute of Brooklyn, Brooklyn, NY, Apr. 1972) 
[2] A. G. Fraser, "On the interface between computers n,: 
communications systems," Commun. Ass. Compu! 3fa,^ 
31-34, July 15, 1969. 
[3] IEEE Instrumentation and Measurements Group 11 t'l 
Digital Interface for Programmable 
..Standard 488, 19'75. 
[4] D.C. Loomis, "Ring communication protocols," 
California, Department of Information and Computer 
Irvine, CA, Tech. Rep. 26, Jan. 19'73. 
[5] J.R. Pierce, "Network for block switching of dais." Ilet1 
Tech../., vol. $1, pp. 1133-1143, July/Aug. 1972. 
[6] A. Hopper, "Data ring at computer laboralory, 
Cambridge," in Computer Science and Technology' 1.,,,', 
Networking. Washington, DC, Nat. Bur. Stand., Nils 
Publ. 500-31, Aug. 22-23, 1977, pp. 11-16. 
[7] P. Zafiropulo and E. H. Rothauser, "Signalling and 
tures in highly decentralized loop systems," i. I%,,' 
on Computer Communication (Washington. Dc'L ll 
Lab., Zurich, Switzerland, pp. 309-315. 
[8] G. Babic and T. L. Ming, "A performance study ,,I Iht 
uted loop computer network (DCLN)," in Proc 
Networking Syrup., (National Bureau of Standards, 
MD, December 15, 1977), pp. 66-76. 
[9] E. R. Hafner et al., "A digital loop communicalmn 
IEEE Trans. Commun., p. $7% June 1974. 
[10] M. V. Wilkes, "Communication using a digital ring." 
PACNETConf. (Sendal, Japan, August 1975), PP .47'5 
111[ M. T. Liu and C. C. Reames, "Message cornmurat.""'" 
and operating system design for the distributed I,-,r ," 
network (DLCN)," in Proc. 4th Annu. Syrup. C,""; ':'t- 
tecture, pp. 193-200 Mar. 1977. 
[12] N. Abramson, "The ALOHA system," Un ivcr'x 
Tech. Rep. No. B72-1, Jan. 1972; also Compltt,'r 
tion Networks. Englewood Cliffs, NJ: Prentice-lta[I. 
113[ R.M. MetraIre, "Packet communication," M.I.T.. I'r"" 
Tech. Rep. 114, Cambridge, MA, Dec. 1973. 
[14] D. R. Boggs and R.M. Metcalfe, "Ethernet: Disrl'utrd 
switching for local computer networks," ConlttL .'$ 
Mach, vol. 19, no. 7, pp. 395-404, July I976. 
[15] E. D. Jensen, "The Honeywell experimental dis n 
ressot-An overview," Computer, Jan. 1978. 
[16] Digital Equipment Corporation, PDP-JI Processor 
Maynard, MA: Digital Equipment Corporation, 1973. 
[17] W. D. Farmer and E. E. Newhall, "An experimcnl.d 
switching system to handle bursty computer 
ACM Syrup. Problems in the Optimization of I)atJ ( 
tion Systems (Pine Mountain, GA, Oct. 1969). PP- 31 34 
{18] A. G. Fraser, "A virtual channel network," 
51-56, Feb. 1975. 
[19] IBM Synchronous Data Link Control General 
GA27-3093-0, File GENL-09, IBM Systems 
Division Publications Center North Carolina, 1974.. 
[20] P Mocka etris and D J arber "Experien. cesttttl 
tributcd computer system" submitted to 
Prorearing , 1978. 
[21] P. Mockapetris, "Design considerations and 
the ARPA LNI name table" Univ California, Dep. 
and Computer Sci., Tech. R'ep. 92, rvine, CA, A?r. 
[22} D. G. Willard, "A time division multiple access s:" c 
communication," Cornput. Des., voI. 13, no. 6. 
June 1974. 
Meisner 
Bu 
ternatit 
and 
Ma 
prohie 
,,Jne 1 
Crocke: 
Ol 
addres 
r mote pk 
add 
------------------------------<page break>-----------------------------
r a cellt 
tion cap,ability 
e to bind 
:d in formatioa 
s resource 
.t put into t 
 evelopment of 
is in the ideti. 
:d, and in th 
center" of tl 
chitecture of tl 
:ations srat,- 
Networks 
r. 1972}. 
nputers and data 
nput. Math., 
p, IEEE 
henration, 
orepurer 
,logy: Lo 
; and frame fl. 
a Pc. Int. 
DC), IBM 
tdy of th dht 
Proc. Computm 
rds, 
nication 
p. 47-55. 
mication  
d loop m 
Compur 
craity of H 
uter Com 
-HAH, 1972. 
.T., ProVM 
)tribut 
cesar 
mntal 
traffic,'L I 
Data 
pp. 31-34 
;ms 
i974. 
:he  
'Apr. 197: 
s system 
o. 6, PP.' 
)c.EDINGS OF THE IEEE, VOL. 66, NO. 11, NOVEMBER 1978 
N. D. Meisner etal., "Time division digital bus techniques imple- 
VI caented on coaxial cable," in Proc. ComputerlVetworking Syrup. 
{National Bureau of Standards, Gaithersburg, MD, Dec. 15, 
1977). 
;d g' E. Kahn, S. A. Gronemeyer, J. Burchild, and R. C. Kurnzel- 
cash, "Advances in packet radio technology," this issue, pp. 
1468-1496. 
.il P' Mockspettis eral., "On the design of local network inter- 
faces," Informat. Process., vol. 77, pp. 427-430, Aug. 1977. 
' 3RpANET Protocol Handboole, Network Information Center, 
' SPA International, Menlo Park, CA, NIC 7014, revised Jan. 1978,. 
'1 V. Cerf and R. KaIin, "A protocol for packet network inter- 
connector," IEEE Trans. Commun., vol. COM-25, No. 1, pp. 
169-178, May 1974. 
 1 L. I'ouzin, "Virtual circuits rs. datagrams--Technical and po- 
litical problems," in AFPS Conf. Proc. (National Computer 
Conf., June 1976), p. 48,3. 
.' D. H. Crocker etal., "Standard for the format of ARPA network 
1517 
text messages," ARPA Network RFC 733, NIC 41952, Nov. 21, 
1977. 
[ 30 } R. H. Thomas, "A resource sharingexecutive for the ARPANET," 
AFIP$ Conf. Proc., vol. 42 (Nat. Computer Conf. and Expo- 
sition, 1973), pp. 155-163. 
[31] D.J. FarbeY and F.H. Heinrich, "The structure of a distributed 
computer system--The distributed file system," in Proc. Int. 
Conf. on Computer Communication (Washington, DC, 1972), 
pp. 364- 370. 
[32] E.G. Manning and R. W. Peebles, "A homogeneous network 
for data sharing communications," Computer Communications 
Network Group, University of Waterloo, Waterloo, ON, Tech. 
Rep. CCNG-E-12, Mar. 1974. 
[33] V. G. Cerf and P. T. Kirstein, "Issues in packet network inter- 
connection," this issue, pp. 1386-1408. 
[34} S. L. Ratlift, "A dynamic routing algorithm for a local packet 
network," S.B. thesis, M.I.T., Department of Electrical Engi- 
neering and Computer Science, Cambridge, MA, Feb. 1978. 
Enhanced Message Addressing Capabilities for 
Computer Networks 
JOHN M. McQUILLAN, MEMBER, IEEE 
In riled Paper 
.Ztract-Thme message addressing modes are described: 
;. Logical addressing, in wldch a permanently assigned address de- 
X0ne or more physical addresses. This permits multiple connections 
the subscriber to the network, as well as other functions. 
'E' roadcast addressing, in which a message is addressed to all sub- 
. Group addressing and multidestination addressing, in which a mes- 
* attics the name of a list of addresses, or the list itself. 
'e methods facilitate many ne.w ways of using computer networks.. 
*9apex 'focuseaton tw basic issues for each method:'efficiency nd 
and recommends implementation approaches in each case. 
performanco improvements ate possible if these addressing 
are implementod with efficient delivery mechanisms. A dis- 
is made between v/rtual eimuit and damgram systems; virtual 
are for logical addressing, while datagrams are prefer- 
group, and multidestination addressing. 
I. INTRODUCTION 
'0W SHOULD one user of a network address messages 
to other users? The answer to this question is funda- 
'mental in defining the appearance of the network to its 
For example, does one user have to know exactly where 
received May 15, 1978; revised July 3, 1978. 
author is with Bolt Beranek and Newman, Inc., Cambridge, MA 
the other is located, or just the region of the network, or is the 
address independent of location? Can he identify himself to 
the network or does the network know who he is automati- 
cally? If self-identification is possible, can he have several 
addresses corresponding to several roles or functions? Can he 
have multiple connections to the network, and can he move 
from one location to another without changing his address(es)? 
Can he send a single message' to a group or list of other dsers 
(e.g., a mailing list) automatically? Can he set up "conference 
calls" with other users, and join conferences in progress? Can 
he send a message to all other users? 
These questions are important for several reasons: some ad- 
dressing modes allow functions which would not be available 
otherwise (e.g., the ability to send a message to a distribution 
list without knowing the identity or location of the members 
of the List), and which are essential for certain types of users 
and applications. Furthermore, these addressing capabilities 
offer opportunities for efficient implementations that would 
not exist otherwise (e.g., a message addressed to a group can 
be transmitted with fewer packets than the equivalent sepa- 
rately addressed messages). The topic of addrepg has re- 
ceived surprisingly Little attention to date; the present paper 
indicates that it may be a fruitful area for further work. 
0018-9219/78/1100-1517500.75  1978 IEEE 
------------------------------<page break>-----------------------------
DVEMBEi 
r a centrefit 
tion apabilil,t 
 to bind 
ls resourc 
-hivs, 
.t put 
.evelopment 
is in the 
:d, and  
centeF' of 
chitecture of tl 
:ations system. 
Networlct 
r. 1972). 
nputers and data 
nput. Math., 
p, IEEE Stand 
henration, IEEg 
s," Univerty 
omputer 
 data," Bell 
ry, UnNslt'ol' 
dogy: Local Art 
rid., NBS 
, and frame slru. 
a Proc. Int. Coq. 
DC), IBM 
;dy of the dhtdb. 
Proc. Cornputt* 
rds, Gait hart, hurl. 
nication systn.' 
al flag," i  
cEEDINGS OF THE IEEE, VOL. 66, NO. 11, NOVEMBER 1978 
N. D. Meisner et el., "Time division digital bus techniques imple- 
mented on coaxial cable," in Proc. ComputerYVetworking Syrup. 
(National Bureau of Standards, Gaithersburg, MD, Dec. 15, 
1977). 
R. E. Kahn, S. A. Gronemeyer, J. Burchfiel, and R. C. Kurnzel- 
man, "Advances in packet radio technology," this issue, pp. 
1468-1496. 
p. Mockapetris et el., "On the design of local network inter- 
faces," Informer. Process., vol. 77, pp. 427-430, Aug. 1977. 
7] ARpANET Protocol Handbook, Network Information Center, 
$RI International, Menlo Park, CA, NIC 7014, revised Jan. 1978. 
 I V. Carl and R. Kalin, "A protocol for packet network inter- 
'connector," IEEE Trans. Cornman., vol. COM-25, No. l, pp. 
169-178, May 1974. 
,; L, l)ouzin, "Virtual circuits vs. datagrams-Technical and po- 
'lifieal problems." in AFIPS Conf. Proc. (National Computer 
Conf., June 1976), p. 483. 
.' D. H. Crocker et al., "Standard for the format of ARPA network 
1517 
text messages," ARPA Network RFC 733, NIC 41952, Nov. 21, 
1977. 
[301 R. H. Thomas, "A resource sharing executive for theARPANET," 
AFIP$ Conf. Proc., vol. 42 (Nat. Computer Conf. and Expo- 
sition, 1973), pp. 155-163. 
[311 D. J. Father and F. H. Heinrich, "The structure of a distributed 
computer system-The distributed file system," in Proc. Int. 
Conf. on Computer Communication 0Kashington, DC, 1972), 
pp. 364-370. 
[321 E.G. Manning and R. W. Peebles, "A homogeneous network 
for data sharing communications," Computer Communications 
Network Group, University of Waterloo, Waterloo, ON, Tech. 
Rep. CCNG-E-12, Mar. 1974. 
{33{ V. G. Cerf and P. T. Kitstein, "Issues in packet network inter- 
connection," this issue, pp. 1386-1408. 
{34 S. L. Ratlift, "A dynamic routing algorithm for a local packet 
network," S.B. thesis, M.I.T., Department of Electrical Engi- 
neering and Computer Science, Cambridge, MA, Feb. 1978. 
Enhanced Message Addressing Capabilities for 
Computer Networks 
JOHN M. McQUILLAN, MEMBER, IEEE 
In vited Paper 
>p. 47-55. 
mication inoomi .ntract-Three message addressing modes are described: 
ed loop omiml }, Logical addressing, in wltieh a permanently assigned address de- 
Cornput? A m ?one or more physical addresses. This permits multiple connections 
.rs the subscriber to the network, as well as other functions. 
tersity of i'  :, [Iroadcast addressing, in which a message is addressed to all sub- 
,uter CornmUnk 
-Hall, 1972;  " 
kT., Pro. ietA ' Group addteeing and multidestination addming, in which a mes- 
 '.', * art/es the name of a list of addres.ms, or the list itself. 
'e methods facilitate many new ways of using computer netwogks.. 
t'apex 'focuseaton tw' basic issues for each method:'efficiency and 
iability, and recommends implementation approaches in each case. 
uricant performan{a; improvements  possible if these addressing 
a0ds are implementl. with efficient delivery mechanisms. A dis- 
/ is made between virtual eimuit and datagram systems; virtual 
sits ate superior for logical addressing, while datagrams are pmfer- 
I I0 broadcast, group, and multidestination addressing. 
I. INTRODUCTION 
0W SHOULD one user of a network address messages 
to other users? The answer to this question is funda- 
mental in defining the appearance of the network to its 
For example, does one user have to know exactly where 
pp. 31-$4 
teral 
;ms 
t 974. 
ce.a with-I 
.he .L 
asCript received May 15, 1978; revised July 3, 1978. 
author is with Bolt Beranek and Newman, Inc., Cambridge, MA 
. Dep. 
Apr. 1' 
s systCffi 
o. 6, PP", 
the other is located, or just the region of the network, or is the 
address independent of location? Can he identify himself to 
the network or does the network know who he is automati- 
cally? If self-identification is possible, can he have several 
addresses corresponding to several roles or functions? Can he 
have multiple connections to the network, and can he move 
from one location to another without chang/ng his address(es)? 
Can he send a single message' to a group or list of other risers 
(e.g., a mailing list) automatically? Can he set up "conference 
calls" with other users, and join conferences in progress? Can 
he send a message to all other users? 
These questions are important for several reasons: some ad- 
dressing modes allow functions which would not be available 
otherwise (e.g., the ability to send a message to a distribution 
list without knowing the identity or location of the members 
of the list), and which are essential for certain types of users 
and applications. Furthermore, these addressing capabilities 
offer opportunities for efficient implementations that would 
not exist otherwise (e.g, a message addressed to a group can 
be transmitted with fewer packets than the equivalent sepa- 
rately addressed messages). The topic of addred,rig has re- 
ceived surprisingly Little attention to date; the present paper 
indicates that it may be a fruitful area for further work. 
0018-9219/78/1100-1517500.75 1978IEEE 
------------------------------<page break>-----------------------------
------------------------------<page break>-----------------------------
------------------------------<page break>-----------------------------
------------------------------<page break>-----------------------------
DVEMBE 
r a cent "ralizlnl 
tion cap abilit,t 
e 16 bind 
.d in fermities 
is resourc 
cideves, whk 
.t put into tl , 
.evelopment 
is in the idetl. 
;d, and in th 
center" of tl .t 
 chitecture of the 
:ations system,' 
Aretworlc$ (Po 7. 
t. 1972}. 
nputers ad data 
nput. Math., . 
p, [EEE 
henration, 
omput 
2EDINGS OF THE IEEE, VOL. 66, NO. 11, NOVEMBER 1978 
1517 
. 13. Meisner et el., "Time division digital bus techniques imple- 
caented on coaxial cable," in Proc. Computer Networking Syrup. 
(National Bureau of Standards, Gaithersburg, MD, Dec. 15, 
1977)- 
g. E. Kern, S. A. Gronemeyer. I. Burchflel, and R. C. Kurnzel- 
caen, "Advances in packet radio technology," this issue, pp. 
1468-1496. 
?. Mockapetris et al., "On the design of local network inter- 
faces," Informat. Process., vol. 77, pp. 427-430, Aug. 1977. 
[RPANET Protocol Handboole, Network Information Center, 
$RI International, Menlo Park, CA, NIC 7014, revised Jan. 1978. 
V. Carl and R. Kalin, "A protocol for packet network inter- 
'connector," EEE Trans. Commun., vol. COM-25, No. 1, pp. 
169-178, May 1974. 
L. l'ouzin, "Virtual circuits vs. datagrams-Technical and po- 
litical problems," in AFPS Conf. Proc. (National Computer 
conf., June 1976), p. 483. 
D. H. Crocker et al., "Standard for the format of ARPA network 
text messages," ARPA Network RFC 733, NIC 41952, Nov. 21, 
1977. 
[ 30 ] R. H. Thomas, "A resource sharing executive for the ARPANET," 
AFIPS Conf. Proc., vol. 42 (Nat. Computer Conf. and Expo- 
sition, 1973), pp. 155-163. 
{311 D. I. Farbet and F. H. Heinrich, "The structure of a distributed 
computer system-The distributed file system," in Proc. Inr. 
Conf. on Computer Communlcatt'on 0/v'ashington, DC, 1972), 
pp. 364-370. 
[32] E.G. Manning and R. W. Peebles, "A homogeneous network 
for data sharing communications," Computer Communications 
Network Group, University of Waterloo. Waterloo, ON, Tech. 
Rep. CCNG-E-12, Mar. 1974. 
{331 V. G. Cerf and P. T. Kitsrein, "Issues in packet network inter- 
connection," this issue, pp. 1386-1408. 
[34] S. L. Ratlift, "A dynamic routing algorithm for a local packet 
network," S.B. thesis, M.I.T., Department of Electrical Engi- 
neering and Computer Science. Cambridge, MA, Feb. 1978. 
Enhanced Message Addressing Capabilities for 
ry, Unive/alt,el ' ': 
logy: Lotall Art  
rid., NBS Special 
: and frame slt. 
a Proc. Int. 
DC), IBM R 
;dy of the ditr. 
Proc. Cornputt* 
rds, Gaithersb ut$. 
nication system.' 
at ting," i Pr0t. 
p. 47-55. 
mication intaoeM 
cd loop coral 1 
CompUter A 
tersity of Hawi 
,uter CommUnk 
-Hall, 1972'; "' 
:.T., ?roje ctA 
2)istributed 
rn: 'A& 
I dittibut 
1973. 
traffic,". 
Data 
;Ills 
t974. 
.he d'. 
..: 
, Dep. 
Apr. 197 
s system  
o. 6. PP", 
Computer Networks 
JOHN M, McQUILLAN, MEMBER, IEEE 
Invited Paper 
'ntract-Thme message addressing modes are described: 
, Logical addressing, in wldc a permanently assigned address de- 
?one or more physical addresses. This permits multiple connections 
,- the subscriber to the network, as well as other functions. 
'-', Broadcast addressing, in which a message is addressed to all sub- 
 ' Group addressing and multidestination addx ssing, in which a mes- 
 ardes the name of a list of addresses, or the list itself. 
'e methods .acilitate many n.w ways of using computer networks.. 
'apex 'focuses.on twO5 basic issues for each method:'efficiency and 
and recommends implementation approaches in each case. 
performance improvements  possible if these addressing 
implemented with efficient delivery mechanisms. A dis- 
made between virtual elmnit and datagram systems; virtual 
ate superior o logical addressing, while datagrams are prefer- 
broadcast, group, and multidestination addressing. 
I. INTRODUCTION 
'0W SHOULD one user of a network address messages 
to other users? The answer to this question is funds- 
'mental in defining the appearance of the network to its 
For example, does one user have to know exactly where 
ausctipt received May 15, 1978; revised July 3, 1978. 
author is with Bolt Bernrick and Newman, Inc., Cambridge, MA 
the other is located, or just the region of the network, or is the 
address independent of location? Can he identify himself to 
the network or does the network know who he is automati- 
cally? If self-identification is possible, can he have several 
addresses corresponding to several roles or functions? Can he 
have multiple connections to the network, and can he move 
from one location to another without chang/ng his address(es)? 
Can he send a single message' to a group or list of other risers 
(e.g., a mailing list) automatically? Can he set up "conference 
calls" with other users, and join conferences in progress? Can 
he send a message to all other users? 
These questions are important for several reasons: some ad- 
dressing modes allow functions which would not be available 
otherwise (e.g., the ability to send a message to a distribution 
list without knowing the identity or location of the members 
of the List), and which are essential for certain types of users 
and applications. Furthermore, these addressing capabilities 
offer opportunities for efficient implementations that would 
not exist otherwise (e.g., a message addressed to a group can 
be transmitted with fewer packets than the equivalent sepa- 
rately addressed messages). The topic of addreg has re- 
ceived surprisingly Little attention to date; the present .paper 
indicates that it may be a fruitful area for further work. 
0018-9219/78/1100-1517500.75  1978 IEEE 
------------------------------<page break>-----------------------------
1516 
~/'.' Communication Lin 
Half-Bridge 
Fig. 12. The "long badge." In this case, the two subnetworks cannot 
be made physically adjacent, so a half-bridge is attached to each, and 
a full-duplex communication link is employed to interconnect the 
two half-bridges. The control and filter functions, and the packet 
buffers, are replica;ed in each half-bridge. 
VIII. CONCLUSION 
The utilization of a technological innovation often occurs 
in two stages. In the first stage, the innovation is exploited 
to perform better the same tasks that were already being 
performed. In the second stage, new applications are dis- 
covered, which could not be reasonably performed or even 
forseen prior to the innovation. Local area networks are now 
on the threshold ol this second stage. While there is still much 
room for creativity in improving the innovation itself-reducing 
the cost of the network interface and increasing its speed and 
convenience-the real challenge lies in identifying new sorts 
of applications that a local area network can make possible. 
Current trends in hardware costs encourage abandoment of 
a single large computer in favor of a number of smaller ma- 
chines. This decentralization of computing power is, for 
many applications. a natural and obvious pattern. In many 
information processing applications, for example, the infor- 
mation itself is distributed in nature, and can most appro- 
priately be manage d by distributed machines. Distributed 
applications can only be constructed, however, if it is possible 
to link their machines together in an effective manner. Subject 
to their geographical limitations, local area networks offer 
a very effective and inexpensive way to provide this inter- 
connection. The greatest impact of local area networks will 
come with the development of operating systems that inte- 
grate the idea of distribution and communication at a fun- 
damental level. 
The impact of local area networks on the decentralization 
of computing is sociological as well as technological. Oper- 
ational control of centralized computers has traditionally 
been vested in the staff of a computer center. The trend 
toward decentralized computing greatly increases the au- 
tonomy. of individual managers in the operation of their 
PROCEEDINGS OF THE IEEE, VOL. 66, NO. 11, NOVEMBI-:R 
machines, and appears to reduce the need for a 
staff of computer managers. The communication capab.. 
made available by local area networks will serve to bind 
decentralized machines together into a unified in[ormat.,t 
processing resource. The effectiveness of this rsourc 
be measured by the degree of coherence it achieves. .... 
in turn, depends upon the care and foresight put int, 
design of the local area network and the developturn: 
standards for communication at all levels. It is in the 
ficalion of areas in which standards are needed, and m t: 
development, that the staff of the "computer center" ,: 
future will find its work. 
REFERENCES 
[1 ]. D'. J.' Farber'nd K'. C. Lrson, "The system arehiteIut,' 
distributed computer system--The communicalion 
presented at the Symposium on Computer NetWork 
technic Institute of Brooklyn, Brooklyn, NY, Apr. 1972) 
12] A. G. Fraser, "On the interface between compmcr, 
communications systems," Cornrnun. Ass. Cornput. 
31-34, July 15, 1969. 
[ 3] IEEE Instrumentation and Measurements Group. II 1.1 
Digital Interface for Programmable 
.Standard 488, 1975. 
[4] D.C. Loomis, "Ring communication protocols," 
California, Department of Information and Compulc 
Irvine, CA, Tech. Rep. 26, Jan. 1973. 
[5] J. R. Pierce, "Network for block switching of dale." 
Tech. J., vol. 51, pp. 1133-1142,, July/Aug. 1972. 
{6] A. Hopper, "Data ring at computer laboratory. 
Cambridge," in Computer Science and Technology I ,,, 
Networking. Washington, DC, Nat. Bur. Stand.. Ntis 
Publ. 500-31, Aug. 22-23, 1977, pp. 11-16. 
[71 P. Zafiropulo and E. H. Rothauser, "Signalling and 
lures in highly decentralized loop systems," in I'rt,, lnt 
on Computer Communication (Washington. '. ltt 
Lab., Zurich, Switzerland, pp. 309-315. 
[8] G. Babic and T. L. Ming, "A performance stud> ,1 Hw 
uted loop computer network (DCLN)," in Proc 
Networking $yrnp., (National Bureau of Standards. 
MD, December 15, 1977), pp. 66-76 
[9] E. R. Hafner et el., "A digital loop communicall,,n t" 
IEEE Trans. Corernun., p. 877, June 1974. 
[10[ M. V. Wilkes, "Communication using a digital rin:." 
PACNET Conf. (Sendal, Japan, August 1975). OP. 47- 5 
l 11 I M. T. Liu and C. C. Reames, "Message communtc:n"" r, 
and operating system design for the distributed l,,,q' 
network (DLCN)," in Proc. 4rh Anna. Syrup. C,'"t; 
teelure, pp. 193-200, Mar. 1977. 
[12] N. Abramson, "The ALOHA system," Uni xcr'' 
Tech. Rep. No. B72-1, Jan. 1972; also Computer  
lion Networks. Englewood Cliffs, NJ: Prentice4hdl. 
Tech. Rep. 114,Cambridge, MA, Dec. 1973. 
[14] D. R. Boggs and R. M. Metcalfe, "Ethernet: D}ml,uted 
switching for local computer networks," Comm...tla 
Mech., vol. 19, no. 7, pp. 395-404, July 1976 
[15] E. D. Jensen, "The Honeywell experimental 
cessot--An overview," Computer, Jan. 1978. 
[16] Digital Equipment Corporation, PDP-IJ ProceSSor 
Maynard, MA: Digital Equipment Corporation, 1073 
[17] W. D. Farmer and E. E. Newhall,"An expcrimcnt.'l 
switching system to handle bursty computer tr.,fti,'. '' 
ACM $yrnp. Problems in the Oprirnization of Igta ' 
tton$ stems Pine Mountain GA Oct 1969),pp.31 
[18] A. G. Fraser, A vtrtual channel network, 
[19] IBM Synchronous Data Link Control General 
GA27-3093-0, File GENL~09, IBM Systems 
Division, Publications Center, North Carolina, 1974. 
[201 P. Mockapetris and D. J. Farbet, ,,Experie.nces/ 
tributed computer system," submitted to ,,, -' 
Proce6'ing, 1978. 
[21] P. Mockapetris, "Design considerations and impleto 
[22] b. G. Willard, "A time division multiple access sys et 
communication," Cornput. Des., vol. 13, no. 0. 
June 1974. 
on 
,"Ad 
1496 
Ockap 
"In/r, 
'Interne 
an 
prob, 
June 
Crock 
addres 
r more pl- 
addxes 
lho ham 
 
SHOI. 
------------------------------<page break>-----------------------------
aetwork is 
hion by 
re one add.-u 
: net'wozk. T 
)nnects the  
'nally, from o, 
,rk appean to  
work, pcrh 
'V, and with 
a be easily 
these two rob. 
aridge betwe 
a them. 
for 
e not h 
ows wi 
t may be d 
interconn 
t erconn  '  
packets 
rk w fio 
y on ch  
monoEte 
ubnetwo  
intert,"  
nong them 
other 
the 
ackets   
each 
and 
ull off" tunSty t 
,ected bY  
letion. 
ARK et al.: AN INTRODUCTION TO LOCAL AREA NETWORKS 
Sub- [i ] -e 
: I \ 
1.11' The structure of a bridge. A bridge would most naturally be 
'teated at a point where the two subnetworks it interconnects have 
:een tnade physically aSiacent. 
.network, it must wait for an opportunity to transmit on 
subnetwork, according to the control structure of that 
network. Packet buffers also aid a bridge in handling 
tantaneous cross-bridge traffic peaks during which the 
:disc offered by one subnetwork exceeds the available 
:?acity of the other. This situation can arise if the bridge 
::erconnects subnetworks of dissimilar data transmission 
::es, or subnetworks of drastically different traffic densities. 
.:a. ever, if the sustained cross-bridge traffic offered is greater 
:xn the target subnetwork can handle, the bridge must 
::ard packets. This is an acceptable course of action, as 
.al area network protocols are generally prepared to handle 
packets. 
' transparency 
{ [he subnetwork structure of a local area network should be 
 nsparent, both to the hosts on the local area network and 
the -outside world"-other networks to which the local 
.::a network may be connected via gateways. A host on the 
cal area network wishing to transmit a packet to another 
. zd have no knowledge of whether that host is on the same 
.Tnetwork, in which case the packet will be received by the 
 lination host directly, or whether the destination host is 
:another subnetwork, in which case the packet is retrans- 
:cd by one or more bridges. In particular, no ordinary 
:.u packets are ever addressed to a bridge; rather, packets 
!::simply addressed to their destination hosts, and may be 
.'cked t:p by a bridge and passed along through other sub- 
!":'*orks, finally reaching their destinations. This is a key 
{areetlon between subnetworking, with bridges, and inter- 
 ::'*'0rking, with gateways: in internetworking, a host about 
:"? i transmit a packet must realize that the host to which it is 
.-. s"::essed is on a different network. The sending host must 
--:..'.'1-'q[?mit the message in a. local .network "wrapper" to an 
":- 70priate gateway, which."unwraps" it, performs protocol 
ff tl 
, .]'-versions, if any, packet fragmentation, etc., as necessary, 
- hen transmits the messgge into the other network. In 
j:networking, protocols are identical over all subnetworks, 
packet sizes are compatible, so that neither protocol con- 
nor fragmentation takes place in the bridges. Finally, 
'as mentioned above, a packet is directly addressed to its 
host, not to a bridge, for hosts do not know that 
.10cal area network is composed of subnetworks. 
eX 
ect 
34]. 
ceiving a 1 
:peat to 
Impact on Network Characteristics 
lP[itting a local area network into subnetworks has little 
on th.e, key characteristics of the network. From the 
of view of the users and hosts of the network, address- 
ti affected only slightly, if at all. Bridges must determine 
lher or not a packet should be picked up for retransmis- 
": one way to aid bridges in this determination is to include 
1515 
a subnetwork field in the address of each host. Other routing 
techniques which have no impact at all on addressing (such as 
complete table look-up of host addresses by the bridges) can 
be implemented, although usually at the expense of greater 
complexity within the bridges. 
Splitting a local area network into subnetworks should have 
no effect on the protocols of the network. One exception 
is if a particular subnetwork technology provides a hardware 
acknowledgment of delivery of a packet (as in the DCS Ring 
Network) [2]; this acknowledgment may only indicate suc- 
cessful receipt by a bridge. However, not all network tech- 
nologies provide hardware acknowledgments, and, in a net- 
work of mixed technologies, host-to-host acknowledgments 
will generaliy be provided by software protocols. Traffic is, 
of course, affected by subnetworking in a positive way. 
Splitting a local area network into subnetworks in a judicious 
way can minimize the overall traffic of the network; bottle- 
necks can be eliminated by using higher bandwidth tech- 
nologies for affected subnetworks. 
The Long-Dtance Bridge 
There are situations in which it is necessary to interconnect 
two subnetworks of a local area network which cannot be 
brought physically adjacent to one another 'so that an ordinary 
bridge may be connected between them. An example of 
this would be a local area network on a university campus, 
with a major research laboratory across town. The laboratory 
may be beyond the range of a twisted-pair ring network or 
a coaxial cable contention bus network; or it may be within 
range, but it may be impossible for the university to install 
its own cables between them. 7 The off campus research lab- 
oratory can be given its own subnetwork, connected to the 
main campus subnetwork via a specialized long-distance 
bridge. 
A long-distance bridge is made tip of two half-bridges at 
either end of a suitable full-duplex point-to-point communi- 
cation link, such as a high-bandwidth common carrier circuit, 
an optical link, or a private microwave link (Fig. 12). Some 
other network technology such as packet radio could be used 
to derive this point-to-point link as desired? Each half-bridge 
contains an appropriate interface to its subnetwork, packet 
buffers, and a controller. In addition to its filtering function, 
the controller of a half-bridge regulates the flow of data over 
the communication link between the two halves of the bridge. 
Of course, )t is possible' that .the bridge communication lnk 
may' be of lower bandwidth than the two subnetworks' it 
interconnects. Additional packet buffers at each half-bridge 
can help to smoothe out traffic peaks, but if the communi- 
cation link is a bottleneck, the long-distance bridge must 
discard packets just as an ordinary bridge does when it is 
overloaded.  
?Although common carfiefs such as the Bell System operating com- 
panies are moving in the direction of leasing wire pairs for transmission 
of digital signals with customer-provided equipment, these circuits are 
not intended for use at the high bandwidth of Iocal area networks, 
and are generally routed through central offices rather than point-to- 
point. 
SAlthough we do not discuss it further in this paper, there is an 
interesting philosophical issue whether the intervening network should 
be viewed in the internetworking context using gateways or as a point- 
to-point link within a single bridge. 
If the bottleneck created by the communication link of a long 
bridge is severe, the local area network advantages of high-bandwidth 
communication with low delay will be forfeited. 
------------------------------<page break>-----------------------------
1514 PROCEEDINGS OF THE IEEE, VOL. 66, NO. 11, NOVEMBER 1971 et M.: A 
the local net. It leaves unanswered the question of how the 
additional features, such as complex flow ont[ol, buffering, 
and speed matching required for the long-haul protocol should 
be implemented. One approach would be to implement them 
in every host that desires to communicate over the long-haul 
network; this implies a programming burden for every ma- 
chine. An alternative would be to implement the additional 
functions in the gateway machine that interconnects the local 
area network to the long-haul network. This would add 
considerable complexity to the gateway, for it will have to 
cope with such problems as the speed differential between 
the two networks without having the benefit of the flow 
control mechanisms normally used for this purpose in the 
long-haul network. At this time, it is not clear whether the 
gateway can assume the entire responsibility for augmenting 
 a local netw.ork virtual circuit protocol' with. the' functions 
required for communication through a long-haul network. 
It would be advantageous to make sure the local area net- 
work protocols are also compatible with other communica- 
tion models, such as single message exchange or selective 
broadcast, that may become available on commercial long-haul 
networks in the future. However, this presupposes that the 
long-haul networks attached to the local area network use 
a two-layer low-level protocol implementation such as that 
described for the local area network, and if the long-haul 
networks do use such an implementation, that they provide 
an interface that allows direct. use of the datagram layer. 
Many current long-haul networks do not provide that interface. 
VII. THE SUBNETWORK CONCEPT 
Resting midway between the monolithic, single-technology, 
local area network and the internetworking environment is an 
approach to local area networking that we term the subnet- 
work concept, which provides for a mix of network technol- 
ogies within a uniform addressing and administrative structure. 
A. General Approach 
A local area network can be composed of a collection of 
subnetworks, possibly implemented with various network 
technologies and perhaps with various transmission rates, but 
using identical software protocols, compatible packet sizes, 
and a single overall homogeneous address space? These 
subnetworks are interconnected by bridges, which are midway 
in complexity between the repefters used in a multisegment 
contention bus network (ETHER-NET) and the gateway pro- 
cessor used between networks in an internetworking environ- 
ment. This general structure is indicated in Fig. 10. A bridge 
links two subnetworks, generally at a location at which they 
are physically adjacent, and selectively repeats packets from 
each of them to the other, according to a "filter function. "a 
In addition, since they buffer the packets they repeat, they 
can perform a speed-matching function as well. 
B. Advantages of Subnetworking 
The subnetworking concept enables a variety of technologies 
and data rates to be utilized in a single local area network, 
each to its best advantage. For example, a network could 
SThe subnetwork concept, as we describe it, is a generalization of 
an approach suggested by Pierce [5] for use with multiple loops ot 
Thc concept of the filter function is introduced in the "filtering 
repeaters" described by Boggs and Metcalfe [ 14]. 
Fig. 10. The subnetwork concept. Here, a local area network i 
posed of a number of subnetworks, linked in some fashion by 
The subnetworks, though of differing technologies, share one addt. 
space, and the same prolocols are used over the entire network: 
the bridges can be simpler tfian'the gaieay whichonnects the 
area network to the long-haul network. Viewed externally, from 
side the dashed line in the figure, the local area network appeam 
monolithic. 
be constructed with a contention bus subnetwork, perhat, 
using coaxial cable originally installed for CATV, and 
ring subnetwork, using twisted pair which can be casdy 
stalled in a crowded laboratory environment. These two 
networks could be of different data rates; the bridge betwet.'. 
the two will handle the speed difference between them. 
Subnetworking 'also provides an orderly means for handhzl 
growth in traffic. Local area networks perform best, provd:a 
high throughput with low delay, when they are not hca.,::, 
loaded. As traffic on a local area network grows with tim: 
if a higher speed technology is not available, it may be dc:: 
able to split the network into two or more interconaccte,: 
subnetworks. Since the bridges which intercohater 
subnetworks are selective in their repeating of packets 
the bridge," not all packets from a subnetwork will 
all other subnetworks, and the traffic density on each 
network will be less than that of the original monolithic 
work. If the partitioning of the hosts into subnetworks ," 
be done along the lines of "communities of interest." '.'" 
that a group of hosts with high traffic rates among them,c:, 
but with substantially lower traffic rates to other he,t, :" 
placed in the same subnetwork, traffic across the bridge* 
be minimized, and a greater fraction of all packets x,1I 
within their subnetwork of origin. 
C. Bridges 
A bridge, depicted in Fig. 11, contains: 
two network interfaces, one appropriate to each of thr '.' 
subnetworks it interconnects, 
a limited amount of packet buffer memory, and 
a control element, which implements an appropriate :::" 
function to decide which messages to "pull off" one 
network and buffer until it has an opportunity to r 
mir it to the other subnetwork. 
The topology of the subnetworks interconnected by'  b,.' 
determines the complexity of its filter function. ..k b.'' 
with a simple filter function can be implemented usin8 a 
state machine as its control element; a complex filter f 
which may involve a periodic exchange of information 
bridges on the network to determine correct routing,  
require the capabilities of a microprocessor [34]. 
A rid e must buffer ackets since unon receiving a 
b g P '  at to Ih 
from one subnetwork which it decides to repe 
The stru 
at apo 
made phys 
:work, it 
bnetwm 
rork. 
( 
offered 
of the 
s 
subnet 
if the 
the targe 
packets 
netw( 
ickets. 
nsparenc 
Tae ubnetwc 
m,parent, bo 
.,: "outsid( 
..etwork m 
'area netw 
.have no k. 
etwork, in 
tion hos 
sub. 
by one 
ar 
addr 
up by a 
finall 
bet 
wit 
a p; 
is on 
the n: 
gatt 
if, 
transr, 
'orking, 
size2 
;nor frag 
mention 
host 
area ne 
ct on N 
a lo 
the: 
view o 
o 
or not 
way tt 
------------------------------<page break>-----------------------------
tputers 
4ces. 
ions from 
omputin 
: area uctw 
actic 
taul netwo 
ty of new 
ng power 
r the 
arge n 
i sm n 
xtreme, 
 each 
1. Such 
by no 
 network, 
n. Dat 
tation w 
i to be _ 
wt a 
ed to each 
ems, sp 
or 
featur 
)VE;",[/(i1K er el..' AN INTRODUCTION TO LOCAL AREA NETWORKS 
aade aee":. I. ha terms of keeping track of the various files that the user 
  _ ]. about, it reques explicit user intervention in order to 
tceenp ' o . . 
a 'ffn, I ,oh through the network and retrieve a fe from another 
of hih-pd local area network wl 
.- f ' ., einate y of these problems, but wl instead make 
,, or e , . 
:s. '. 'l,a more obvious to the user the overhead that the protocol 
poses on the transfer of data. Clearly, what is needed is 
'{ further tegration of the local area network into the file 
.,tem and user authentication mechanism of the individua 
' , systems, so that interchange of infomarion between 
:0,ratlng 
' various macnes can he done with less direct user ter- 
.:ntion. Some attempts have been made to do ts within 
: context of the ARPANET. RSEXEC a an example of a 
tocol which makes fes on various TENEX operating 
.,stems  the ARPANET appear to the user to exist on a 
.e macne [301. 
[e design of operating system structures to take full 
vantage of the capabities of loc area networks repre- 
cnts he current edge of research in this area. Examples of 
7erati:g systems that incorporate a high-speed local area 
.:[work into thek arctecture are the Distributed Computing 
.,stem [3 1 ], the Distributed Loop Operating System [ 11 ], 
.: MININET [32]. 
V'[. INTERCONNECTION OF LOCAL AREA NETWORKS 
WITH OTHER NETWORKS 
   Motivation for Interconnection 
.B was mentioned earlier, a local area network will be only 
.Tart of the overall communication system used by the hosts 
:uched to it. A very important use of the local area network 
'ja be to provide an interconnection between hosts attached 
: a local area network and other networks such as long-haul 
cket-switched networks and point-to-point transmission 
't: The appll. '-'ks. The advantage of this method of interconnection is 
n -be support ,ucect cost, by taking advantage of the fact that connection 
ones already t  a host to a local area network is relatively inexpensive. 
logging into  ::tead of connecting all machines directly to the long-haul 
,le Transfer Pro' i:twork, one can connect all the host computers to the local 
[261. Wheao t:u network, with one machine, the gateway, connected to 
todified to tJ ;:th the local area network and the long-haul network. 
al area net,to ! ' 
.hat the pro. bhm ' ! Protocol Compatibility 
>f modifY'.'tl here are two pitfalls that should be avoided when plan- 
the netwoi'k m :.g for the interconnection of a local area network with a 
ark appear,t. :g-haul network. On the'one hand, long-haul networks 
eht of the, olx' :rently cannot provide  of the functions that local area 
the ARP;AI.., 'etvorks can. If a local area network is initially designed to 
iser as anel '*'e only the function of connecting hosts to a long-haul 
a file frir '-work, the protocols of the local network may be designed 
alien he ml/.l :serve only the needs of communicating with the long-haul 
[achine,'  lt-. 0rk, and 
1 and the, 1 may not support the other functions that make 
ishes to P<," :0eel area network especially attractive. On the other hand, 
vo disadv"tl '' local network is initially designed with no thought given 
, .'a i. the possibility that it may be interconnected with another 
ith raovmg("ork, the protocols designed for it may lack the necessary 
U.ffll._!'aeralit . For example, the addressing structure used on 
by th. a,,,. ' y 
'nd the data.local area network may not be able to express destinations 
spent estabt_[Btsicle the local network. In either case, the only after-the- 
: otheni,. lution is to implement a second set of protocols for 
1 
,uter U ..'5. cal area network, so that different protocols are used 
able tltrougll!. mtercommumcatlon with long-haul networks and for 
, local f'de 41 services. This proliferation of protocols is undesirable, 
1513 
as it adds to the cost of software development as}ociated 
with each new host added to the local area network. To 
avoid these pitfalls, it is important that all the functions a 
local area network is to provide must be considered from 
the very inception of the design of the network, and the 
protocols for the network must be designed to support that 
entire range of functionality. 
Fortunately, initial experiments with protocols for local 
area networks suggest that a uniform approach to protocol 
design can support both specialized local network functions 
and interconnection with other networks, provided that both 
functions are envisioned from the start. Although the pro- 
tocols used in the local area network must be made slightly 
more general to handle the internetworking situation, there 
is no interference with the realization of the purely local 
network functions. For example, a more general address 
field must be used to specify the destination of a message, 
but the only overhead implied if this same addressing struc- 
ture is used for purely local messages is additional bits in 
the message to hold a presumably larger address. Since band- 
width is inexpensive, the bits "wasted" on ttiis larger address 
are presumably irrelevant. 
A slightly more difficult problem, one that is still being 
studied, is the problem of speed matching between the local 
area network and the long-haul network. As this paper has 
characterized the difference between local nets and long-haul 
nets, it is reasonable to presume that the local network will 
have a much higher data rate. If a host sends a large number 
of packets into the local area network with an ultimate des- 
tination to be reached through the long-haul network, the 
packets may arrive at the gateway much faster then the 
gateway can pass them to the long-haul network. Some 
mechanism will be required to prevent the gateway from 
exhausting its buffer space. The speed matching problem 
is not unique to the gateway between the local area network 
and the long-haul network; it occurs any time two networks 
of differing speed are connected together. (The problem may 
be more extreme here, though, due to the greater speed dif- 
ference that can be encountered between local area and some 
long-haul networks. Satellite networks with speeds com- 
patible to local networks are quite conceivable, yet are a 
long-haul technology.) A general discussion of the problems 
of internetworking, and some proposed solutions can be 
found in a companion paper by Cerf and Kirstein in this 
issue [33]. 
At the nekt highe. r level of protocol;one fin'd.s facilities that 
support various communications models, such as virtual 
circuits, broadcast, and message exchange. In interconnecting 
to a long-haul network we are chiefly forced to deal with a 
virtual circuit model, since that is the only pattern of com- 
munication usually supported by commercial long-haul 
networks. Here, it is appropriate to use a virtual circuit pro- 
tocol in the local area network as sireilar as possible to that 
used in the long-haul network, so that translation between 
the two is easy. Although there is not as much practical 
experience available in the area of network interconnection 
as could be desired, it appears that one can develop a virtual 
circuit protocol for a local area network that is a compatible 
subset (in the sense of using compatible packet formats and 
control algorithms) of a suitable long-haul virtual circuit 
protocol. This means that it is not necessary to implement 
two complete virtual circuit protocols, one for internal local 
network use and the other for communication out through 
------------------------------<page break>-----------------------------
1512 
cast message has been successfully received? By one of the 
possible recipients? By all of the possible recipients? One 
appropriate strategy is to rely on the high-level application 
to deal with these problems as a part of its normal operation, 
rather than have the low-level protocol concern itself with 
issues of flow control or acknowledgment at all. 
3} Protocol Structure: Based on the previous observations, 
a two-layer structure is a very natural one for low-level pro- 
tocols in a local area network. The bottom layer should 
provide the basic function of delivering an addressed message 
to its (one or many) destinations. This level corresponds 
to the concept of a datagram network [28]. It should also 
take on the responsibility of detecting that a message has 
been damaged in transit. To this end it may append a 
checksum to a message and verify the checksum on receipt. 
.However, t.his layer proba.bly should not take on .thc..respon- 
sibility of ensuring 'that messages are delivered, End delivered 
in the order sent, since different applications have different 
needs and requirements for these functions. The first layer 
might be implemented entirely in hardware; however, if the 
packet size, addressing structure, or routing topology of the 
hardware is not sufficient to provide adequate message size, 
process addressing, or broadcast selectivity, some software 
help will be needed to make up the difference. 
Above this first layer should be made available a variety 
of protocols. One protocol should support a virtual cimuit 
mechanism, since a virtual circuit is definitely the appropriate 
model for a great deal of the communication that will go on 
in any network, local or otherwise. As alternatives to the 
virtual circuit protocol, there should be mechanisms for 
sending isolated messages, for message exchange communi- 
cation, and additional alternatives to provide support for 
message models other than the ones we have discussed here. 
For example, transmission of digitized speech requires a 
communication model with some but not all of the attributes 
of the virtual circuit; in particular, rehability is of less con- 
cern than timeliness of arrival. 
B. Applications of Local Area Networks; Higher Level 
Protocols 
In the pevious section we considered low-level protocols 
for a local area network. These protocols exist, of course, 
to support higher level protocols, Which, in turn, support user 
applications. In this section we %rill consider a number of 
applications for which local area net-works are suited. 
1) Access to Common Resources: The model of computing 
most common over the last few years is that of a large cen- 
tralized computer, with the only remote components being 
terminals and, perhaps, a few other I/O devices. Line control 
protocols such as SDLC [19] were created to serve this sort of 
arrangement. A simpIe but very important application of a 
local area network is to generalize this picture very slightly 
to include more than one central computer. As the total 
workload grows to exceed the capacity of a single machine, 
a common solution is to procure a second machine, and to 
'divide the applications and workload between the two. The 
communication problem to be solved in this arrangement is 
simple but critical-to allow an individual terminal to have 
access to both of the central machines. A local area network 
can solve this problem, and provide some additional capa- 
bilities as well. For example, if the central facility has special- 
ized I/O devices such as plotters or microfilm writers, they 
PROCEEDINGS oF THE IEEE, VOL. 66, NO. 11, NOVEMBER 
can be placed on the local area network and made accesbl; 
to both central machines-an advantage if a device is expens., 
and is not heavily enough loaded to justify having one for 
each computer. Further, I/O devices can be placed 
from the central site but convenient to users; for exampl: 
a line printer can be placed near a cluster of users. 
This pattern of sharing among several computers can 
expanded to include more than just I/O devices. In fac: 
the network can be used to move computations from 
machine to another in order to spread the computing 
equally. The high speeds available in the local area 
make this sort of load leveling much more practical than .,., 
the bandwidths traditionally available on long-haul netwo:k 
2) Decentralized Computing: A wide variety of new 
for a local area network arises if the computing power 
able is not strongly.centralizefi...Le.t us consider th alternala L 
oi a computing environment consisting of a large number 
relatively small machines, each dedicated to a small numbc.- 
of users or a small number of tasks. In the extreme, wc car. 
look to the future and imagine the day when each user 
a computer on his desk instead of a terminal. Such a 
pletely distributed computing environment by no 
eliminates the need for an interconnecting network. 
users will still need to exchange information. Data 
containing the results of one person's computation will ncc.'. 
to be shipped through the local area network to be tscd 
input to other tasks. Users will wish to communicate 
each other by exchanging computer mail, as is now 
over the ARPANET [29]. Users will still want accc.x 
specialized resources which cannot be provided to each 
resources such as large archival storage systems, spcciaht 
output devices such as photo typesetters, or 
points to long-haul networks. All of these features can 
made available through the local area network. 
3} Protocol and Operating System Support: The apphc 
tions outlined in the previous paragraph can be suppor:c'! 
by high-level protocols very similar to the ones already :-'- 
existence in the ARPANET: TELNET for logging into 
remote system through the network, and File Transfer P:*' 
tocol for exchanging data between machines [26]. When,-' 
examines how these protocols might be modified to 
advantage of the special attributes of a local area 
for example, its higher speed, one discovers that the proNero 
is not one of modifying the protocols, but of modifying 
operating system of the hosts connected to the network "-' 
that the services available through the network appear to - 
a natural part of the programming environment of the 
ating system. The File Transfer Protocol in the AR P^-x}'l 
for example, is usually made available to the user as an 
command which he may invoke to move a file from 
machine to another. As part of this invocation he may - 
required to identify himself at the other machine, and 
explicit file names in the syntax of the local and the for 
machine, describing exactly what action he wishes to perfo 
This particular view of file transfer has two disadvant'es 
First, there is a lot of overhead associated with moving  f 
Much of the delay in moving the file seen by the. 
nothing to do with the time required to send the clara s,  
through the network, but is rather the time spent establBl-m 
the connection, identifying the user at the other site. 
Second, the file system on the local computer undertSo 
nothing about the existence of files accessible throU 
network. No matter how sophisticated the local file s> ' 
iKct al.: A 
:.tcrms of 
bout, it 
througl. 
The 
ore obvi 
on the 
integ 
and use 
syste 
mat 
Som 
of 
whict 
in the 
[ 
design , 
of t 
5the curre: 
syste 
t? 
[311, t 
INTERC 
J 
menti 
of the o, 
to it. 
to prov: 
area: 
The ad' 
cost, b 
to a 
of con; 
one c: 
local a 
tocol Co 
are tw 
the in 
netw 
cannc 
can. 
the 
the p 
only t] 
and n 
area net 
eal netw 
:possibili 
the p 
Fe 
area n 
the Ioc 
area 
------------------------------<page break>-----------------------------
OVEMBER'.I .0jRK et al.: AN INTRODUCTION TO LOCAL AREA NETWORKS 
. 
 -tl the process to receive the data is scheduled and requests 
s the process. In case b) an interrupt  sent to 
.... :(. ot, or b) th urgent poter points to data not ready 
t*reciving process, indicating that data should b read 
ding mechanism  TCP mqued that a host b capable 
':i nderstandg and responding to a special interrupt signal 
; th data stream, even if the signal had no meaning to the 
:t in its paicular application of TCP. The urgent pointer, 
:in, is a spl mechanism that mets the nds of sopsti- 
 a n, ed host plementations without placing an excessiw 
stream,   .xden on unsophisticated hosts. 
)rk, and r 
The rece ) Special Capabilities: The other aspect of low-level 
.1 to proc  .*0/OCO for local ara networks to be discussed is the manner 
 haaa  : wch protocols must be structured to take advantage of, 
a by a p :J provide to higher lvIs, the unique capabilities of local 
.t:works. 'Convention low-level protocols have provided 
. function best characterized as a bidirectional stream of 
o mody h. ..:s between two communicating entities-a irtual circuit. 
 networ It 2e firtual circt is implemented by a process that prods 
'ol mec t4uenced delive of packets at the destination. While a 
in the rv :ual circuit is on portant fo of communication, two 
ssage  it il .:,ers easily provided by a local network are very useful in 
es the sch .,aftcrY of contexts. These are message exchange communi- 
roduced [ :ton, whr the packets exchanged am not viewed as being 
lnicatg  :tinMrs of a sequenc of packets but are rather isolated 
ay. In a.. :;kanges, and broadcast communication in wch messages 
exablT: ' :: nt not to one paicular recipient but to a selected sub- 
e is recei, 
;e to this 
sage is sent 
 millisecon 
d to wait. 
rhe Iow-led 
for Comput 
rt of proI 
ma d 
b on 
trntwor 
,ced R 
tl TCP du 
atures, pa 
f these  
to the T. 
o sn 
y p qf 
model  
;iver thst 
a somw 
a. 
ata str 
d, when ' 
, tntt 
pointer' 
)oyond  
trgent P 0g 
n th 
hat pw. 
rgnt o7' 
:: of the potential recipients on the network. 
a) Message exchange: A typical example of a message 
::tange is the situation in which one message asks a question 
: another provides the answer. For example, if there are 
 !arge number of services provided by nodes connected to 
local net, it is disadvantageous to maintain, on every node, 
 table giving all of the addresses of these, for whenever a 
uage is made in the network address of any service, every 
:de's table will need to be revised. Rather, it may be ad- 
ntageous to maintain, as a network service, a facility which 
',';2 take the name of a desired entity and give back its net- 
i,xk address. Clearly, the pattern of communication with 
:a sen'ice is not one of opening a connection and exchang- 
!u.' a large number of messages, but instead is a simple two- 
,::sage exchange, with a query of the form "What is the 
'c2ess of such and such a service?" and a reply of similarly 
!ple form. While a virtual circuit could be used for this 
:{ange, .it is'unneded..anct uses. excessive resou.rces. '. - ' 
b) Broadcast: The exanlple given above demonstrates 
:: need for a broadcast mechanism. If the service described 
:,:ve is intended to provide he address of network services, 
": can we find the address of this service itself?. An obvious 
c:ution is to broadcast the request for information. The 
;::ry then takes the form "Would anyone who knows the 
eress of such and such a network service please send it to 
':?" There are many other examples, some apparently trivial 
!' nonetheless very useful, for support of broadcast queries 
  local network. A microprocessor with no calendar clock 
broadcast a request for the time of day. A new host 
to the network for the first time may broadcast a 
x-sage announcing its presence, so that those who maintain 
les may discover its existence and record-the fact. Broad- 
 raechanisms in the low-level protocols can also be quite 
ul in implementing higher level protocols for such appli- 
as document distribution to multiple host nodes, and 
and video conference calls. 
1511 
Why are these alternative models of communication not 
commonly found in traditional networks? The first, and 
perhaps most important reason is that long-haul networks 
have not been extensively exploited for applications in wtdch 
computers directly query other computers with individual, 
self-contained queries. Instead, the major use of long-haul 
networks has been for long-term, human-initiated interactions 
with computers, such as direct terminal use of a remote 
computer, or long-term attachments of remote job entry 
stations. Such human interactions usually involve many 
message exchanges between sender and receiver, so that the 
extra delay and cost of initial setup of a virtual circuit is 
insignificant-perhaps even recovered by reducing redundant 
information in each message As new applications such as 
distributed data base systems become more important, these 
alternative models will become important in long-haul net- 
works, but long-lived connections between terminals and 
host computers continue to dominate the usage. 
The second reason is precisely that discussed in the previous 
section concerning the relative simplicity of protocols for 
local area networks-a variety of functions performed in con- 
ventional networks are very difficult to understand except in 
the context of a sequence of ordered messages (a virtual 
circuit) exchanged between two nodes. For example, flow 
control is normally handled in network protocols by placing 
an upper bound on the number of messages which may be 
flowing at any one time between the sender and the receiver. 
This concept has meaning only in the restricted case where 
the sender and the receiver are a well-identified pair exchang- 
ing a sequence of messages. There is no obvious equivalent 
of flow control that can be applied to situations where sender 
and receiver communicate by sending arbitrary unsequenced 
messages, or where a sender broadcasts to several receivers. 
Similarly, if efficiency requires use of the shorthand version 
of an address for communication between the sender and 
the receiver, this clearly implies that the sender and the 
receiver have-negotiated this address, and agree to use it 
over some sequence of messages. Again, this idea makes no 
sense if communication is isolated in unsequenced messages. 
Another problem that is traditionally handled in the con- 
text of a sequence of messages is the acknowledgment to the 
sender that the receiver has correctly received a message. If 
messages are sequenced, acknowledgment can be very easily 
done by acknowledging the highest member of the sequence 
that has been successfully. received. If messages bear .no 
relatiOnihip 'to each other, 'then iach must be identified 
uniquely by the sender, and acknowledged uniquely by the 
receiver. This .increases the complexity and overhead of 
acknowledgment. However, in most cases where message 
exchange communication is the appropriate underlying com- 
munication model, no acknowledgment mechanism is required 
of the low-level protocol at all. For example, if a micropro- 
cessor system asks the time of day, it is not at all necessary 
to acknowledge that the query has been successfully received; 
the receipt of the correct time is sufficient acknowledgment. 
Similarly, a request for a network address is acknowledged by 
a return message that contains the desired address. Depend- 
ing on a low-level acknowledgment message to handle all 
failures can be dangerous, for it may lead to the practice 
of assuming that acknowledgment of receipt of a message 
implies that the message was processed at a high level. 
In the broadcast context, it is difficult to formulate a use- 
ful definition of acknowledgment that can .be supported by 
a low-level protocol. What does it mean to say that a broad- 
------------------------------<page break>-----------------------------
1510 
PROCEEDINGS OF THE IEEE, VOL. 66, NO. I1, NOVEMBER 1971 
et el.: A 
sire. For example, the ARPANET NCP host-to-host protocol 
[26] initiates a connection using a 56-bit (net, host, socket) 
identifier for the'destination, but then goes through a nego- 
tiation so that instead of sending this 56-bit value on sub- 
sequent messages, a 32-bit (net, host, link) value can be sent 
instead. It is not clear whether this conservation of bits is 
appropriate even in a tong-haul network; in a local area net- 
work, where bandwidth is inexpensive, it is clearly irrelevant. 
Other examples of ways in which extra header space can be 
used to simplify processing include: 
I) having a single standard header format with fields in 
fixed locations, rather than having optional fields or 
multiple packet types; field extraction at the host can 
be optimized, reducing processing time; 
2) using addresses that directly translate into addresses of 
'queues, buffers, port, or processes at ire'receiver'with- 
out table lookup. 
b} Simplified flow control, etc.: The low transmission 
delay inherent in local area networks, as well as their high 
data rate, can eliminate the need for complex buffer manage- 
ment, flow control, and network congestion control mecha- 
nisms. Consider, for example, flow control: the problem of 
assuring that messages arrive at the recipient at the rate it 
can handle, neither too fast, so that its buffers overflow, nor 
too slow, so that it must wait for the next message after 
processing the previous one. In a long-haul network, a re- 
ceiver typically allocates to the transmitter enough buffer 
space for several messages following the one currently pro- 
cessed by the receiver, so that messages can be placed in 
transit well before the receiver is ready to process them. 
Considerable mechanism is required to keep the sender and 
the receiver properly synchronized under these circumstances. 
In a local area network, the delay will typically be low enough 
for a much simpler flow control mechanism to be employed. 
For example, one can use the very simple strategy of not 
sending a message until the recipient has explicitly indicated, 
by a message in the other direction, that it is ready for it. 
In contrast, a network using communication satellites has 
such a high transmission delay that very complex predictive 
flow control algorithms must be used to obtain reasonable 
data throughput. 
It is crucial to understand that other factors may obviate 
these simplifications. While the data rate and delay char- 
acteristics of a local area network can render it essentially 
instantaneous, its speed cannot eliminate the intrinsic dis- 
parity that may exist between the capabilities of two hosts 
that wish to communicate with each other. These disparities 
may not show up when the two hosts are communicating 
through a long-haul network whose characteristics are so 
constraining that the principal problem is dealing with the 
restrictions of the network. While protocols for local area 
networks need not include mechanisms designed to cope 
with the limitations of the network itself, it is still necessary 
to design protocols with sufficient generality to cope with 
disparities between the capabilities of machines wishing to 
communicate through the network. Such disparities include: 
1) mismatch between the rate at which hosts can generate 
and absorb data; 
2) host delay between the time a packet is received and the 
time it is successfully processed and acknowledged: 
3) amount of buffer space available at the sender and the 
receiver. 
Fig. 9. The urgent pointer mechanism. By transmitting a new. 
value of the urgent pointer, a pointer into the data stream, a 
can indicate the data bufferred in the sender, network, and 
are holding up data that must be processed quickly. Thereccivc 
then adjust his use of the data stream flow control to process 
bufferred data until the urgent data is processed. The shaded area 
dicates the location of potentially urgent data specified by a patticute: 
ugent pointer value. 
o,o o,o or b) t 
,  .__. __________ ___.___..  .... [eceiving 
 /// p ...... ' 'ro cossad 
!derstandi] 
i*-e data str 
is a 
lSecit 
orks. 
Further, considerable effort may be required to modify 
software to provide a suitable interface to the network. 
one were to consider the simple flow control mecharux::: 
mentioned earlier, where a message is sent in the rcvc:, 
direction requesting transmission of each message as n 
needed, one would discover that in many cases the scheme 
was unworkable, not because the network introduced ml, 
erable delays, but because the hosts communicating ::' 
each other themselves introduced excessive delay. In a 
host with a time-shared operating system, for example. 
real time that elapses from the time a message is receive,: 
one or more processes are scheduled in response to this 
sage, and that process runs, to the time a message is sent 
response, could well run into a large number of milliqccon,!, 
milliseconds during which the other host is forced to wit. 
c) Example of protocol simplification: The 
protocol initially proposed for the Laboratory for Computer 
Science Network at M1T is an example of the sort 
that results when simplicity of mechanism is a primary 
goal. The Data Stream Protocol (DSP) was based on 
Transmission Control Protocol (TCP) used in internetworktx--' 
experiments sponsored by the Defense Advanced Rcsca:.r 
Projects Agency [27], but evolved from original TCP d,c . 
the continuing desire to simplify the protocol features. 
formats, and implementation strategies. Most of these 
ficalions have subsequently been incorporated into the T(T 
One specific example is the mechanism used to signal in:r' 
rupts and other urgent messages that are logically part of 
sequence of data in a virtual circuit. The basic model is 
the sender occasionally wants to signal the receiver that " 
data in the stream preceding the signal (buffered somewhc:r 
in the network) must be scanned immediately in order c 
respond promptly to some other important signal. A 
nism is provided whereby a pointer into the data strca:n 
maintained at the receiver, wh/ch can be moved, when 
sender chooses, to point to a more recently tr ansmitt'2 
piece of data. This pointer, called the urgent pointer. 
be used to indicate the point in the data stream beyond 
there is no more urgent data. (See Fig. 9.) The urgent pointe: 
can be implemented in two ways, depending upon the natUre 
of the host receiving the message. In the case of a sire? l 
(e.g., microprocessor) host dedicated to a task that proCCs 
the incoming stream as it arrives, the host need not P 
the urgent pointer, since by design, all data, urgent or nol. 
are processed as quickly as possible. In contrast, on a 
time-shared host,' data need not be processed until 
host im 
on unso 
for lc 
protc 
,v/de to 
Co 
factio n be 
between t 
?,.,fixtual cirt 
.nced dell' 
circuit i 
Iety of cm 
where t 
*bers of a 
Imges, and 
.,int not to 
[,f the poten 
I:] Message 
nge is the 
!,another pr 
i._lg e numbe; 
i2101 ' net, it i 
ge is made 
[te the m 
lrL addrs. 
ice is n 
' large num 
o exchan 
 of such 
ple fo 
Ige, it is c 
' Broaden. 
d for a 
  intend 
n we fin 
gn  to 
; then' tak 
 of suck 
> There ar 
nethele 
fl netw( 
broadcast 
to 
e annoul 
may disc 
echanism 
m ple 
as docu 
eeh and x 
------------------------------<page break>-----------------------------
NOVEii!.,..CI. ARK et mi.: AN INTRODUCTION TO LOCAL AREA NETWORKS 
.basic design principle of the transceiver is that it must 
?resent a high impederice to the bus except when it is trans- 
itting and actualy aving the bus. This is essential to the 
,pcration of the contention bus network; a large number of 
vers on the bus must not present impederice lumps or 
any way interfere with a transceiver wch is actively 
ansmitting. 
Jhe receiver must be able to detect and properly receive 
]round 
r entire 
rs and solated  
referenced to cb 
one point alol I 
each t ranscelvet Uel 
tble via a tap. 
 ent to the netwct 
. its host, an appro 
ected to span 
30 ft or so, '.'sil' 
'or better reHab. 
.ns over a s 
:arismission 
conditiong & 
tterconnect  
:aken in 
y d peffo 
: our case s'ay 
is cable t'' 
signed and b  
 Integence ' 
,r vaous 
wing function:' 
,* ,;, 
of tha sn) ':" 
nals from the most distant point on the bus; in addition, 
.: must be able to detect a colliding signal while its companion 
::nsmitter is itself driving the bus. This requirement impacts 
:be choice of an encoding scheme for data transmitted on 
:.e bus. A number of data encoding schemes can be used, all 
:f which require that the transmitter be able to place the 
  ::ansmission medium in two distinct states. At first glance, 
.: might seem that three states could be used: the quiescent, 
. :-impedence state, to indicate that no transmission is in 
i :togtess, and two active driver states, for example +V and 
 I'. However, with two active driver states, when two or 
n0r network nodes attempt to transmit simultaneously, 
:he cable will be driven to different voltage levels at different 
r0ints. This has two effects. First, it places a severe load 
:n drivers. Second, it makes the detection of a colliding 
,:gnal more difficult than it needs to be. On the other hand, 
 .:' the transceiver drives the cable to some voltage to represent 
, ,ne signaling state, and represents the other signaling state 
:y not driving the cable, the problem of overloaded drivers 
. eliminated, and the task of collision detection is greatly 
cmplified. Collision detection is accomplished looking at 
'.he bus during the transmitter's quiescent state. Any signal 
:resent during that time must come from another transceiver, 
ind constitutes a collision. The transceiver can detect an 
coming signal with 20-dB attenuation, which corresponds 
'about 1 km of the particular cable used. 
Fhe transceiver must be able to cope with ground potential 
:,irefences at the various network hosts. Isolation is accom- 
:Iished by high-speed optocouplers and an isolated power 
apply which enables the major circuit elements of the trans- 
:dyer to be referenced to cable ground, rather than local 
:0st ground. Finally, the fault detection, or watchdog 
atcuit examines the output of the driver to guard against 
::aasceiver failures which drive the bus and disrupt the net- 
,'0rk. The signaling states used by the transceiver result in 
:he driver being quiescent approximately 50 percent of the 
':me; if the driver remains on steadily for several bit-times, 
.: is. deemed to. be faulty, and the.fault .detector dis.counect.s 
a power, which, of course, returns' the driver to its high- 
-pedence state. -. 
$] Complexity of the Local Network Interface: In its 
:ment form, the LNI omprises about 350 TTL SSI and 
$[ integrated circuits, apportioned as follows: 
PDP-I 1 full-duplex DMA 100 
Name table controller 25 
Name table cells (8 provided) 90 
Network-oriented portion 120 
Test and diagnostic 15 
Total 350 
Count of 120 chips for the network-oriented portion of 
LN1, excluding the associative name table, is well within 
1509 
the capabilities of current large-scale integration. As the 
field of local area networking matures, and standards are 
arrived at, it is likely that integrated circuit manufacturers 
will add local area network controllers to their product lines, 
to take their place alongside other LSI data communication 
chips which are already available, making high-performance 
local area network technology available at a very reasonable 
cost. 
V. PROTOCOLS FOR LOCAL AREA NETWORKS 
As in long-haul networks, local area network protocols 
can be divided into two basic levels-low-level protocols 
and high-level protocols. At each level, the characteristics 
of local networks impact effects on protocol design and 
functionality. 
A. Low-Level Protocols 
The term low-level protocol identifies the basic protocols 
used to transport groups of bits through the network with 
appropriate timeliness and reliability. The low-level protocols 
are not aware of the meaning of the bits being transported, 
as distinct from higher level application protocols that use 
the bits to communicate about remote ations. Two aspects 
of local area networks have a very strong impact upon the 
design of low-level protocols. First, the high performance 
.achievable purely through hardware technology enables the 
simplification of protocols. Second, low-level protocols 
must be designed to take advantage of and preserve the special 
capabilities of local networks, so that these capabilities can 
be utilized, in turn, by higher level application protocols. 
We will explore these two issues in this section. 
1) Simplicity: Local area networks must support a wide 
variety of hosts, from dedicated microprocessors to large 
time-sharing systems. The existence of extremely simple 
hosts (such as microprocessor-based intelligent terminals, 
or even microprocessor printer controllers) leads to a desire 
for simple, flexible, low-level protocols that can be econom- 
ically implemented on small hosts, while not compromising 
the performance of large hosts. Supporting a variety of hosts 
also leads to a difficult software production and maintenance 
problem that can be ameliorated somewhat by having a. 
protocol that is simple to implement for each new kind of 
host. Although quite a variety of hosts has been attached 
to long-haul networks such as the ARPANET, the problem 
of software development has not been too severe, since each 
individual host in such erw'ronments usually has:a software  
maintenance and development staff. In the local area network 
context where a variety of computers are all maintained by 
a small programming staff, the arguments for simplicity in 
protocol design are far stronger in our view. 
In a long-haul network, complexity results from strategies 
that attempt to make as much of the costly network band- 
width as possible available for transport of high-level data. 
The costs of a local area network are concentrated instead 
in the host interfaces, the hosts themselves, and their soft- 
ware. Two factors lead to the simplicity of low-level local 
area network protocols. 
a} Unrestricted use of overhead bits: Bandwidth is in- 
expensive in a local area network; there is little motivation 
to be concerned with protocol features designed to reduce 
the size of the header or overhead bits sent with each message. 
This is in contrast to protocols developed for networks making 
the more conventional assumption that bandwidth is expen- 
------------------------------<page break>-----------------------------
1508 
of a message. In a contention bus or contention ring network, 
the output machine may transmit only when the network 
is quiet. The "token present" signal is replaced by a "network 
quiet" signal. In the ring network, the reception control 
section signals the transmission control section if it detects 
another token in the midst of its receipt of the message the 
transmission control section sent; this has its analogue in the 
collision detection capability of the contention network. In 
both cases, the LNI nmst abort transmission of its message 
and take corrective action. In the ring network this is an 
error condition, an exception; more than one control token 
is present in the ring. In the contention network, a collision 
is an expected event. Both situations can be handled by the 
LNI reporting the event to host software, which can attempt 
.to restart a token on the ring, in the ring network case, or 
a. pply a retransmission backoff algorithm in the contention 
network case. 
A better solution for the contention network is to modify 
the transmission control section to execute a simple retrans- 
mission backoff algorithm in hardware. This requires that 
the entire message remain accessible to the transmission con- 
trol section without host intervention. The FIFO buffer 
cannot be used in this situation; a complete packet buffer 
which is not erased until the message has been successfully 
transmitted is an appropriate alternative. 
Two features of the ring network LNI's transmission con- 
trol section are not needed in the contention bus network 
version: the data repeater which passes bits from the receive 
side of the LNI to its transmit side when the LN1 is not 
transmitting a message, and the token generator which 
places a new token or connector onto a quiescent ring. Of 
course, the connector is'a brief sequence of bits, and there 
is no good motivation to delete it from the beginning of 
messages transmitted by the contention bus version of the 
LNI. In fact, retention of the connector at the head of a 
message results in fewer changes to the input machine of 
the LNI. It can use its token/connector detector to signal 
the beginning of an incoming message. Its function remains 
the same, for the most part; extra connectors detected in 
the middle of a message indicate a collision, just as they do 
for the ring network version. However, in the contention 
bus network, because bits are not repeated from one LN1 
to another, there is no way to set the match/accept bits for 
the benefit of the transmitting LNI, and the match/accept 
field of the message cannot be usbd. 
The signal conditioning section of the LNI undergoes an 
interesting transformation. For a contention ring network, 
of course, the signal conditioning section remains the same. 
However, 'for a contention bus network, the logic levels of 
the LNI must be converted to appropriate signal levels and 
waveforms for the coaxial cable of the bus. This is done in 
a two-step process. First, a cable transceiver is added to the 
configuration. To minimize impedence mismarches, reflec- 
tions, etc., the transceiver is located immediately adjacent 
to the network cable, and is often packaged separately from 
the LNI. 4 It is connected to the cable either directly, or via 
4This has become common practice in local area networking; the 
networking transmission medium is generally not brought into the 
racks, equipment bays, etc., of a host computer where it would be 
subject to accidental disconnection and other physical abuse that 
could disrupt the entire network. Instead, the connection point for 
a host is designed to be physically stable: a box on the wall, above 
a false ceiling, etc. 
PROCEEDINGS OF THE IEEE, VOL. 66, NO. I 1, NOVEMBER 1?! I K er el.: 
.... io, cab',e ., Ie basic c 
!ta big 
,oh ..... terfoce me .... Z [ation of 
/ (e g, [N[) 
i  from 
host ', i '1 I 
J ; more d 
'0 transce 
Fig. 8. A typical bus transceiver. The opto-isolators and isolated 
supply permit the drivers and receivers to be referenced t, g' 
ground; the cable, in turn, is grounded at only one point 
length, eliminating problems that would result if each transceiver 
the cable to local host ground. 
a short stub cable attached to the main cable via a tap. x,-.,transce 
ond, since the transceiver is located adjacent to the nct* ' ences at 
bus cable, and the LNI is located next to its host, an 
priate transmission scheme must be selected to span :'ily which 
intervening distance. For distances up to 30 ft orso. ",t:;.' lter to be 
ended" drivers and receivers will suffice. For better rch.':: ' lground. 
greater distances, or both, differential signals over ash c: :>: dt exami 
twisted pair can be used-just as in the transmission m[:':*l. eiver fa 
of the ring network itself. So, the signal conditioning >cc:. ' . The s 
of the original LN1 can be modified to interconnect itc I',! j.:.dn.'ver be 
and the cable transceiver. J, if the 
4} The Cable Transceiver.' The care taken in the dc'-F-deeme d 
of a cable transceiver for a contention bus network '*i,9wer, w 
strongly influence the overall reliability and perform'!encest 
of the network. Therefore, we conclude our case stud? TM !Cornple; 
examining a hypothetical contention bus cable transcC:'- form 
shown in Fig. 8, that is similar to one designed and built : 
the CHAOS Network at the MIT Artificial IntelligenCe 
tory; it is typical of transceivers built for various comCn'.: 
bus networks. P5 
The cable transceiver performs the following functions: N 
N 
1) transmission (cable driving); N 
2) reception; T 
3) power and ground isolation; 
4) collision detection; 
5) transceiver fault detection ("watchdog"). 
The first three of these constitute part of the signal o. ? 
tioning function described previously. exc 
------------------------------<page break>-----------------------------